Re: [RFC PATCH v1 26/31] ARC: Build system: Makefiles, Kconfig, Linker script
On Wednesday 02 January 2013 08:18 PM, Arnd Bergmann wrote:
> On Wednesday 02 January 2013, Vineet Gupta wrote:
>> On Wednesday 07 November 2012 07:43 PM, Arnd Bergmann wrote:
>>> On Wednesday 07 November 2012, Vineet Gupta wrote:
>>> +menu "ARC CPU Configuration"
>>> +
>>> +choice
>>> + prompt "ARC Core"
>>> + default ARC_CPU_770
>>> +
>>> +config ARC_CPU_750D
>>> + bool "ARC750D"
>>> + help
>>> + Support for ARC750 core
>>> +
>>> +config ARC_CPU_770
>>> + bool "ARC770"
>>> + select ARC_CPU_REL_4_10
>>> + help
>>> + Support for ARC770 core introduced with Rel 4.10 (Summer 2011)
>>> + This core has a bunch of cool new features:
>>> + -MMU-v3: Variable Page Sz (4k, 8k, 16k), bigger J-TLB (128x4)
>>> + Shared Address Spaces (for sharing TLB entires in MMU)
>>> + -Caches: New Prog Model, Region Flush
>>> + -Insns: endian swap, load-locked/store-conditional, time-stamp-ctr
>>> +
>>> +endchoice
>>> Same thing here: If the different CPUs can in theory run the same kernel
>>> code, they should allow that. It doesn't stop you from making the default
>>> to enable only one of them and optimize for that case.
>> Background: ARC770 supports newer instructions (LOCK/SCOND) + MMUv3 which
>> are not
>> available on ARC750. So code needs to be built differently for each. Having
>> said
>> that above config items don't have any code under them - they are just high
>> level
>> selectors for correct MMU versions and e.g. whether we allow the usage of
>> new insns.
> So a kernel built for ARC750 could potentially run on an ARC770, but not use
> all the features, right?
Only for features which are non conflicting - so even now a CONFIG_ARC_CPU_750
built kernel (so no LLOCK/SCOND support) will run fine on 770 hardware (which
has
LLOCK/SCOND)- assuming everything else being constant. However MMUv3 (770 only)
has a different programming model vs. MMUv2 (e.g. TLB descriptor layout among
others) hence a kernel for MMU v2 "simply" can't run on MMUv3 w/o making
runtime-checks or runtime-overrides (akin to function pointers) in things like
TLB
refill handlers and such.
> The way we handle this on ARM and PowerPC is to allow selecting each CPU
> individually,
> but falling back on the common subset. So you could build
> a kernel that supports running on ARC750 and on ARC770, but that would
> make it impossible to use SMP, so on an ARC770 SMP machine, it would
> only run on the first CPU.
Good for pre-built distros and such ! Nice concept - I like it.
> If ARC770 cannot actually run the MMU_V2 code, that would mean that they
> are indeed mutually exclusive by design,
Given the immense hardware configurability of ARC, all crazy combinations are
possible - how many are practically used is a different topic. So someone could
in
theory build 770 with MMUv2 and infact the current build system even allows
that.
See ARC_CPU_{750,770} are only about selecting a bunch of defaults (MMU ver,
LLOCK) - to prevent the user from hand doing that. So lets say we rip off both
of
these (to emulate kernel built for one running on other) - then it would boil
down
to letting support for both v2 and v3 co-exist (not to forget there's also an
arcane historic v1). Now these fellows really are mutually exclusive by design:
* code written for v3 won't work on v2 (e.g. ARC_REG_IC_PTAG doesn't exist)
* code written for v2 won't work on v3 (e.g ARC_REG_IC_PTAG needs to be written
for correct behaviour)
> unless you also support a NOMMU
> kernel. In that case you could only build a kernel for both 750 and 770
> if you don't use the MMU. That would be much less interesting for actually
> running things, but it could still make sense for build testing.
>
> If you don't need NOMMU support otherwise (I forgot whether or not you
> have this), you should of course not implement it just for this.
NOMMU is not supported yet.
So how do we conclude on this topic - given the caveats above ?
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] timer: vt8500: Move system timer to clocksource
On Wed, 2013-01-02 at 23:35 -0800, Dmitry Torokhov wrote:
> On Thu, Jan 03, 2013 at 04:25:09PM +1300, Tony Prisk wrote:
> > +static void __init vt8500_timer_init(void)
> > +{
> > + struct device_node *np;
> > + int timer_irq;
> > +
> > + np = of_find_matching_node(NULL, vt8500_timer_ids);
> > + if (!np) {
> > + pr_err("%s: Timer description missing from Device Tree\n",
> > + __func__);
> > + return;
> > + }
> > + regbase = of_iomap(np, 0);
> > + if (!regbase) {
> > + pr_err("%s: Missing iobase description in Device Tree\n",
> > + __func__);
> > + of_node_put(np);
> > + return;
> > + }
> > + timer_irq = irq_of_parse_and_map(np, 0);
> > + if (!timer_irq) {
> > + pr_err("%s: Missing irq description in Device Tree\n",
> > + __func__);
> > + of_node_put(np);
> > + return;
>
> You are forgetting to unmap the regbase here.
Also I think it'd be nicer to write something like:
struct device_node *np;
int timer_irq;
const char *reason;
np = of_find_matching_node(NULL, vt8500_timer_ids);
if (!np) {
reason = "timer";
goto error;
}
regbase = of_iomap(np, 0);
if (!regbase) {
reason = "iobase";
goto error_put;
}
timer_irq = irq_of_parse_and_map(np, 0);
if (!timer_irq) {
reason = "irq";
goto error_remap;
}
...
error_remap:
unmap...;
error_put:
of_node_put(np);
error:
pr_err("%s: Missing %s description in Device Tree\n",
__func__, reason);
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] timer: vt8500: Move system timer to clocksource
On Thu, Jan 03, 2013 at 04:25:09PM +1300, Tony Prisk wrote:
> +static void __init vt8500_timer_init(void)
> +{
> + struct device_node *np;
> + int timer_irq;
> +
> + np = of_find_matching_node(NULL, vt8500_timer_ids);
> + if (!np) {
> + pr_err("%s: Timer description missing from Device Tree\n",
> + __func__);
> + return;
> + }
> + regbase = of_iomap(np, 0);
> + if (!regbase) {
> + pr_err("%s: Missing iobase description in Device Tree\n",
> + __func__);
> + of_node_put(np);
> + return;
> + }
> + timer_irq = irq_of_parse_and_map(np, 0);
> + if (!timer_irq) {
> + pr_err("%s: Missing irq description in Device Tree\n",
> + __func__);
> + of_node_put(np);
> + return;
You are forgetting to unmap the regbase here.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] zswap: add to mm/
On Wed, Jan 02, 2013 at 11:04:24AM -0800, Dan Magenheimer wrote: > > From: Dave Hansen [mailto:d...@linux.vnet.ibm.com] > > Subject: Re: [PATCH 7/8] zswap: add to mm/ > > Hi Dave -- > > I suspect we are in violent agreement but just to make sure... > > Although zswap is the current example, I guess I am discussing > a bigger issue, which IMHO is much more important: How should > compression be utilized in the kernel (if at all)? Zswap is > simply one implementation of in-kernel compression (handling > anonymous pages only) and zcache is another (handling both > anonymous pages and pagecache pages). Each has some > limited policy, and policy defaults built-in, but neither IMHO > is adequately aware of (let alone integrated with) MM policy to > be useful to a broad set of end users and to be enabled by default > by generic distros. > > > On 01/02/2013 09:26 AM, Dan Magenheimer wrote: > > > However if one compares the total percentage > > > of RAM used for zpages by zswap vs the total percentage of RAM > > > used by slab, I suspect that the zswap number will dominate, > > > perhaps because zswap is storing primarily data and slab is > > > storing primarily metadata? > > > > That's *obviously* 100% dependent on how you configure zswap. But, that > > said, most of _my_ systems tend to sit with about 5% of memory in > > reclaimable slab > > The 5% "sitting" number for slab is somewhat interesting, but > IMHO irrelevant here. The really interesting value is what percent > is used by slab when the system is under high memory pressure; I'd > imagine that number would be much smaller. True? Not at all. The amount of slab memory used is wholly dependent on workload. I have plenty of workloads with severe memory pressure that I test with that sit at a steady state of >80% of ram in slab caches. These workloads are filesytem metadata intensive rather than data intensive, that's exactly the right cache balance for the system to have Thinking that there is a fixed amount of memory that you should reserve for some subsystem is simply the wrong approach to take. caches are dynamic and the correct system balance should result of the natural behaviour of the reclaim algorithms. The shrinker infrastructure doesn't set any set size goals - it simply tries to balance the reclaim across all the shrinkers and relative to the page cache. If a cache is under allocation pressure, then it will grow to the point that reclaim is balanced with the allocation pressure and they won't grow any further. If the allocation pressure drops, then the cache will shrink if overall memory pressure is maintained. > > > I don't claim to be any kind of expert here, but I'd imagine > > > that MM doesn't try to manage the total amount of slab space > > > because slab is "a cost of doing business". >From the above it should be obvious that the MM subsystem really does manage the total amount of slab space being used > > > However, for > > > in-kernel compression to be widely useful, IMHO it will be > > > critical for MM to somehow load balance between total pageframes > > > used for compressed pages vs total pageframes used for > > > normal pages, just as today it needs to balance between > > > active and inactive pages. > > > > The issue isn't about balancing. It's about reclaim where the VM only > > cares about whole pages. If our subsystem (zwhatever or slab) is only > > designed to reclaim _parts_ of pages, can we be successful in returning > > whole pages to the VM? > > IMHO, it's about *both* balancing _and_ reclaim. One remaining > major point of debate between zcache and zswap is that zcache > accepts lower density to ensure that whole pages can be easily > returned to the VM (and thus allow balancing) while zswap targets > best density (by using zsmalloc) and doesn't address returning > whole pages to the VM. And so the two subsystems need different reclaim implementations. And, well, that's exactly what we have shrinkers for - implmenting subsystem specific reclaim policy. The shrinker infrastructure is responsible for them keeping balance between all the caches that have shrinkers and the size of the page cache... > > The slab shrinkers only work on parts of pages (singular slab objects). > > Yet, it does appear that they function well enough when we try to > > reclaim from them. I've never seen a slab's sizes spiral out of control > > due to fragmentation. > > Perhaps this is because the reclaimable slab objects are mostly > metadata which is highly connected to reclaimable data objects? > E.g. reclaiming most reclaimable data pages also coincidentally > reclaims most slab objects? No, that's not true. Caches can have some very complex heirarchies with dependencies across multiple slabs and shrinkers, not to mention that the caches don't even need to be related to filesystems or the page cache. Indeed, look at the shrinkers attached to the memory pools used by the acceleration engines for graphics
Re: linux-next: manual merge of the kvm tree with the s390 tree
Hi Stephen,
On Thu, 3 Jan 2013 12:06:50 +1100
Stephen Rothwell wrote:
> Today's linux-next merge of the kvm tree got conflicts in
> arch/s390/include/asm/irq.h and arch/s390/kernel/irq.c between commit
> bfb048f594d5 ("s390/irq: remove split irq fields from /proc/stat") from
> the s390 tree and commit 7e64e0597fd6 ("KVM: s390: Add a channel I/O
> based virtio transport driver") from the kvm tree.
>
> I fixed it up (I think - see below) including the following merge fix
> patch and can carry the fix as necessary (more action may be required).
>
> From: Stephen Rothwell
> Date: Thu, 3 Jan 2013 12:04:39 +1100
> Subject: [PATCH] KVM: s390: fix for IOINT_VIR name change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/s390/kvm/virtio_ccw.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
> index 1a5aff3..f94a0b1 100644
> --- a/drivers/s390/kvm/virtio_ccw.c
> +++ b/drivers/s390/kvm/virtio_ccw.c
> @@ -745,7 +745,7 @@ static struct ccw_driver virtio_ccw_driver = {
> .set_offline = virtio_ccw_offline,
> .set_online = virtio_ccw_online,
> .notify = virtio_ccw_cio_notify,
> - .int_class = IOINT_VIR,
> + .int_class = IRQIO_VIR,
> };
>
> static int __init pure_hex(char **cp, unsigned int *val, int min_digit,
I surprises me a bit that there is only one hunk in the cleanup patch.
I expected three, the above for virtio_ccw.c, one for irq.c and another
for irq.h. I checked the resulting tree which is correct! The merge diff
has a '++' line for irq.c/irq.h:
irq.h:
+ IRQIO_PCI,
+ IRQIO_MSI,
++ IRQIO_VIR,
NMI_NMI,
- NR_IRQS,
+ CPU_RST,
irq.c:
+ [IRQIO_PCI] = {.name = "PCI", .desc = "[I/O] PCI Interrupt" },
+ [IRQIO_MSI] = {.name = "MSI", .desc = "[I/O] MSI Interrupt" },
++ [IRQIO_VIR] = {.name = "VIR", .desc = "[I/O] Virtual I/O Devices"},
[NMI_NMI]= {.name = "NMI", .desc = "[NMI] Machine Check"},
+ [CPU_RST]= {.name = "RST", .desc = "[CPU] CPU Restart"},
Magic ?
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 2/2] usb: host: tegra: Resetting PORT0 based on information received via DT.
Tegra USB host driver is using port instance number,
to handle some of the hardware issues on SOC e.g. reset PORT0
twice etc. As instance number based handling looks ugly,
making use of information passed through DT for achieving this.
Signed-off-by: Venu Byravarasu
Acked-by: Alan Stern
---
drivers/usb/host/ehci-tegra.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index acf1755..55a9cde 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -43,6 +43,7 @@ struct tegra_ehci_hcd {
struct usb_phy *transceiver;
int host_resumed;
int port_resuming;
+ bool needs_double_reset;
enum tegra_usb_phy_port_speed port_speed;
};
@@ -184,7 +185,7 @@ static int tegra_ehci_hub_control(
}
/* For USB1 port we need to issue Port Reset twice internally */
- if (tegra->phy->instance == 0 &&
+ if (tegra->needs_double_reset &&
(typeReq == SetPortFeature && wValue == USB_PORT_FEAT_RESET)) {
spin_unlock_irqrestore(&ehci->lock, flags);
return tegra_ehci_internal_port_reset(ehci, status_reg);
@@ -666,6 +667,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
clk_prepare_enable(tegra->emc_clk);
clk_set_rate(tegra->emc_clk, 4);
+ tegra->needs_double_reset = of_property_read_bool(pdev->dev.of_node,
+ "nvidia,needs-double-reset");
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(&pdev->dev, "Failed to get I/O memory\n");
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 1/2] arm: tegra: Add new DT property to USB node.
As Tegra USB host driver is using instance number for resetting
PORT0 twice, adding a new DT property for handling this.
Signed-off-by: Venu Byravarasu
---
.../bindings/usb/nvidia,tegra20-ehci.txt |2 ++
arch/arm/boot/dts/tegra20.dtsi |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
index e9b005d..6ea765a 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
@@ -27,3 +27,5 @@ Optional properties:
registers are accessed through the APB_MISC base address instead of
the USB controller. Since this is a legacy issue it probably does not
warrant a compatible string of its own.
+ - nvidia,needs-double-reset : boolean is to be set for some of the Tegra2
+USB ports, which need reset twice due to hardware issues.
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index fe35c72..7f74339 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -384,6 +384,7 @@
phy_type = "utmi";
nvidia,has-legacy-mode;
status = "disabled";
+ nvidia,needs-double-reset;
};
usb@c5004000 {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 0/2] usb: tegra: modifying port reset based on instance number
Tegra USB host driver is using port instance number, to handle some of the hardware issues on SOC e.g. reset PORT0 twice etc. As instance number based handling looks ugly, added a new property to USB DT node for this purpose. Modified host driver to make use of the information passed through DT to reset the port second time. Venu Byravarasu (2): arm: tegra: Add new DT property to USB node. usb: host: tegra: Resetting PORT0 based on information received via DT. .../bindings/usb/nvidia,tegra20-ehci.txt |2 ++ arch/arm/boot/dts/tegra20.dtsi |1 + drivers/usb/host/ehci-tegra.c |6 +- 3 files changed, 8 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] arm :omap :DMA: fix a bug on reserving the omap SDMA channels
Hi, On Sunday 30 December 2012 02:13 AM, ahema...@gmail.com wrote: From: ahemaily The variable dma_lch_count used for comparison (omap_dma_reserve_channels <= dma_lch_count) before it initialized to the value from omap_dma_dev_attr : d->lch_count. I change the place of dma_lch_count initialization to be before the comparison. Signed-off-by: Abdelrahman Hemaily --- arch/arm/plat-omap/dma.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index c76ed8b..cb3e321 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -2014,12 +2014,12 @@ static int __devinit omap_system_dma_probe(struct platform_device *pdev) d = p->dma_attr; errata = p->errata; - + dma_lch_count = d->lch_count; + if ((d->dev_caps & RESERVE_CHANNEL) && omap_dma_reserve_channels && (omap_dma_reserve_channels <= dma_lch_count)) d->lch_count = omap_dma_reserve_channels; - dma_lch_count = d->lch_count; By removing this line, you are effectively not assigning d->lch_count after reserving. So the patch should only change dma_lch_count in the above "if statement" to d->lch_count Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/7] leds: leds-pwm: Device tree support
On Wed, Jan 02, 2013 at 06:10:13PM -0800, Bryan Wu wrote: > Hi Peter, > > I merged this patchset into my for-next branch already. > > Thanks for pushing this. Hi Bryan, Did you also take the PWM patches (3-5)? I was going to add those to my tree, but if you already take them feel free to add my Acked-by. Thierry pgpOVUlRboSOj.pgp Description: PGP signature
Re: Fairly reproduceable crash in 3.7.1 Null pointer rb_erase+0xc4/0x292
Marc MERLIN writes:
> I had pretty repeated crashes when plugging power back into my running
> laptop, but the display just freezes and I can't get a dump.
> For the crash here, I did: suspend to RAM, plug power back in, wake up.
> Laptop crashed about 3 seconds after wakeup.
Sounds like https://bugzilla.kernel.org/show_bug.cgi?id=51661 which is
fixed by 3935e89505a1c3ab3f3b0c7ef0eae54124f48905 ("watchdog: Fix
disable/enable regression"), expect that in 3.7.2...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] sysctl: Enable PARISC "unaligned-trap" to be used cross-arch
PARISC defines /proc/sys/kernel/unaligned-trap to runtime toggle
unaligned access emulation.
The exact mechanics of enablig/disabling are still arch specific, we can
make the sysctl usable by other arches.
Signed-off-by: Vineet Gupta
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: "Eric W. Biederman"
Cc: Serge Hallyn
---
arch/parisc/Kconfig |1 +
init/Kconfig|8
kernel/sysctl.c |7 ++-
3 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index b77feff..8c76095 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -20,6 +20,7 @@ config PARISC
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
+ select SYSCTL_ARCH_UNALIGN_ALLOW
select HAVE_MOD_ARCH_SPECIFIC
select MODULES_USE_ELF_RELA
select CLONE_BACKWARDS
diff --git a/init/Kconfig b/init/Kconfig
index e188f9f..e64bb18 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1240,6 +1240,14 @@ config SYSCTL_ARCH_UNALIGN_NO_WARN
unaligned access emulation going on under the hood.
see arch/ia64/kernel/unaligned.c for reference
+config SYSCTL_ARCH_UNALIGN_ALLOW
+ bool
+ help
+ Enable support for /proc/sys/kernel/unaligned-trap
+ Allows arches to define/use @unaligned_enabled to runtime toggle
+ the unaligned access emulation.
+ see arch/parisc/kernel/unaligned.c for reference
+
config KALLSYMS
bool "Load all symbols for debugging/ksymoops" if EXPERT
default y
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 840fd5e..c4cd655 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -157,13 +157,16 @@ extern int sysctl_tsb_ratio;
#ifdef __hppa__
extern int pwrsw_enabled;
-extern int unaligned_enabled;
#endif
#ifdef CONFIG_IA64
extern int unaligned_dump_stack;
#endif
+#ifdef CONFIG_SYSCTL_ARCH_UNALIGN_ALLOW
+extern int unaligned_enabled;
+#endif
+
#ifdef CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN
extern int no_unaligned_warning;
#endif
@@ -548,6 +551,8 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+#endif
+#ifdef CONFIG_SYSCTL_ARCH_UNALIGN_ALLOW
{
.procname = "unaligned-trap",
.data = &unaligned_enabled,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] Convert PARISC sysctl to be generic
Hi, This came out ARC Port's review by Arnd where he suggested using the existing sysctl knobs in parisc and/or ia64 for runtime controlling unaligned access emulation. Turns out that ARC port needs bit of both. The common sysctl knobs are now #ifdef based on init/Kconfig options which the corresponding arches now select in their Kconfigs. No other arch code is touched (although code has not been compile tested). If this patch is ACKable, I would request you to please take this patch via your arch tree - to avoid any merge-hassles and other interdependencies later. P.S. I've deliberately NOT added the new items at the end of arch/*/Kconfig, to avoid any merge conflicts going further - anyhow both the ia64/parisc Kconfigs are not sorted either. Thx, -Vineet Vineet Gupta (1): sysctl: Enable PARISC "unaligned-trap" to be used cross-arch arch/parisc/Kconfig |1 + init/Kconfig|8 kernel/sysctl.c |7 ++- 3 files changed, 15 insertions(+), 1 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] Convert IA64 sysctl to generic
Hi, This came out ARC Port's review by Arnd where he suggested using the existing sysctl knobs in parisc and/or ia64 for runtime controlling unaligned access emulation. Turns out that ARC port needs bit of both. The common sysctl knobs are now #ifdef based on init/Kconfig options which the corresponding arches now select in their Kconfigs. No other arch code is touched (although code has not been compile tested). If this patch is ACKable, I would request you to please take this patch via your arch tree - to avoid any merge-hassles and other interdependencies later. P.S. I've deliberately NOT added the new items at the end of arch/*/Kconfig, to avoid any merge conflicts going further - anyhow both the ia64/parisc Kconfigs are not sorted either. Thx, -Vineet Vineet Gupta (1): sysctl: Enable IA64 "ignore-unaligned-usertrap" to be used cross-arch arch/ia64/Kconfig |1 + init/Kconfig |8 kernel/sysctl.c |9 +++-- 3 files changed, 16 insertions(+), 2 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] sysctl: Enable IA64 "ignore-unaligned-usertrap" to be used cross-arch
IA64 defines /proc/sys/kernel/ignore-unaligned-usertrap to control
verbosw warnings on unaligned access emaultion.
While the exact menchaincs (ignore/shout) are still arch specific, we
can make the sysctl usable by other arches.
Signed-off-by: Vineet Gupta
Cc: Tony Luck
Cc: Fenghua Yu
Cc: "Eric W. Biederman"
Cc: Serge Hallyn
---
arch/ia64/Kconfig |1 +
init/Kconfig |8
kernel/sysctl.c |9 +++--
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 3279646..5fb1064 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -40,6 +40,7 @@ config IA64
select ARCH_THREAD_INFO_ALLOCATOR
select ARCH_CLOCKSOURCE_DATA
select GENERIC_TIME_VSYSCALL_OLD
+ select SYSCTL_ARCH_UNALIGN_NO_WARN
select HAVE_MOD_ARCH_SPECIFIC
select MODULES_USE_ELF_RELA
default y
diff --git a/init/Kconfig b/init/Kconfig
index 7d30240..e188f9f 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1232,6 +1232,14 @@ config SYSCTL_EXCEPTION_TRACE
help
Enable support for /proc/sys/debug/exception-trace.
+config SYSCTL_ARCH_UNALIGN_NO_WARN
+ bool
+ help
+ Enable support for /proc/sys/kernel/ignore-unaligned-usertrap
+ Allows arch to define/use @no_unaligned_warning to possbly warn about
+ unaligned access emulation going on under the hood.
+ see arch/ia64/kernel/unaligned.c for reference
+
config KALLSYMS
bool "Load all symbols for debugging/ksymoops" if EXPERT
default y
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c88878d..840fd5e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -161,10 +161,13 @@ extern int unaligned_enabled;
#endif
#ifdef CONFIG_IA64
-extern int no_unaligned_warning;
extern int unaligned_dump_stack;
#endif
+#ifdef CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN
+extern int no_unaligned_warning;
+#endif
+
#ifdef CONFIG_PROC_SYSCTL
static int proc_do_cad_pid(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos);
@@ -911,7 +914,7 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_doulongvec_minmax,
},
#endif
-#ifdef CONFIG_IA64
+#ifdef CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN
{
.procname = "ignore-unaligned-usertrap",
.data = &no_unaligned_warning,
@@ -919,6 +922,8 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+#endif
+#ifdef CONFIG_IA64
{
.procname = "unaligned-dump-stack",
.data = &unaligned_dump_stack,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: tegra: Set SCU base address dynamically from DT
Stephen Warren wrote @ Wed, 2 Jan 2013 20:02:53 +0100: > On 12/16/2012 11:18 PM, Hiroshi Doyu wrote: > > Set Snoop Control Unit(SCU) register base address dynamically from DT. > > Hiroshi, what's the status on this patch series? I think Rob had > comments/objections on patch 4; are you going to post an updated series, > or is this series replaced by patch 3 in your Tegra114 series? As Rob suggested, at least, SCU base address should be detected in common code, scu_of_init() even if DT /cpus is the primary way to detect # of cores. I'll repost later. This patch can be done independent of Tegra114 series. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] lp8788-ldo: fix a parent device on devm_gpio_request()
Use 'platform_device' rather than i2c client device node.
Argument is added in lp8788_config_ldo_enable_mode().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-ldo.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regulator/lp8788-ldo.c
index 40403e9..416bb60 100644
--- a/drivers/regulator/lp8788-ldo.c
+++ b/drivers/regulator/lp8788-ldo.c
@@ -616,10 +616,11 @@ static struct regulator_desc lp8788_aldo_desc[] = {
},
};
-static int lp8788_gpio_request_ldo_en(struct lp8788_ldo *ldo,
+static int lp8788_gpio_request_ldo_en(struct platform_device *pdev,
+ struct lp8788_ldo *ldo,
enum lp8788_ext_ldo_en_id id)
{
- struct device *dev = ldo->lp->dev;
+ struct device *dev = &pdev->dev;
struct lp8788_ldo_enable_pin *pin = ldo->en_pin;
int ret, gpio, pinstate;
char *name[] = {
@@ -647,7 +648,8 @@ static int lp8788_gpio_request_ldo_en(struct lp8788_ldo
*ldo,
return ret;
}
-static int lp8788_config_ldo_enable_mode(struct lp8788_ldo *ldo,
+static int lp8788_config_ldo_enable_mode(struct platform_device *pdev,
+ struct lp8788_ldo *ldo,
enum lp8788_ldo_id id)
{
int ret;
@@ -693,7 +695,7 @@ static int lp8788_config_ldo_enable_mode(struct lp8788_ldo
*ldo,
ldo->en_pin = pdata->ldo_pin[enable_id];
- ret = lp8788_gpio_request_ldo_en(ldo, enable_id);
+ ret = lp8788_gpio_request_ldo_en(pdev, ldo, enable_id);
if (ret)
goto set_default_ldo_enable_mode;
@@ -717,7 +719,7 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
return -ENOMEM;
ldo->lp = lp;
- ret = lp8788_config_ldo_enable_mode(ldo, lp8788_dldo_id[id]);
+ ret = lp8788_config_ldo_enable_mode(pdev, ldo, lp8788_dldo_id[id]);
if (ret)
return ret;
@@ -773,7 +775,7 @@ static int lp8788_aldo_probe(struct platform_device *pdev)
return -ENOMEM;
ldo->lp = lp;
- ret = lp8788_config_ldo_enable_mode(ldo, lp8788_aldo_id[id]);
+ ret = lp8788_config_ldo_enable_mode(pdev, ldo, lp8788_aldo_id[id]);
if (ret)
return ret;
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] lp8788-ldo: fix a parent device in _probe()
The lp8788-ldo is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc, registering regulators and device kernel messages.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-ldo.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regulator/lp8788-ldo.c
index 3792741..40403e9 100644
--- a/drivers/regulator/lp8788-ldo.c
+++ b/drivers/regulator/lp8788-ldo.c
@@ -712,7 +712,7 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
struct regulator_dev *rdev;
int ret;
- ldo = devm_kzalloc(lp->dev, sizeof(struct lp8788_ldo), GFP_KERNEL);
+ ldo = devm_kzalloc(&pdev->dev, sizeof(struct lp8788_ldo), GFP_KERNEL);
if (!ldo)
return -ENOMEM;
@@ -721,7 +721,7 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
if (ret)
return ret;
- cfg.dev = lp->dev;
+ cfg.dev = pdev->dev.parent;
cfg.init_data = lp->pdata ? lp->pdata->dldo_data[id] : NULL;
cfg.driver_data = ldo;
cfg.regmap = lp->regmap;
@@ -729,7 +729,7 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
rdev = regulator_register(&lp8788_dldo_desc[id], &cfg);
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
- dev_err(lp->dev, "DLDO%d regulator register err = %d\n",
+ dev_err(&pdev->dev, "DLDO%d regulator register err = %d\n",
id + 1, ret);
return ret;
}
@@ -768,7 +768,7 @@ static int lp8788_aldo_probe(struct platform_device *pdev)
struct regulator_dev *rdev;
int ret;
- ldo = devm_kzalloc(lp->dev, sizeof(struct lp8788_ldo), GFP_KERNEL);
+ ldo = devm_kzalloc(&pdev->dev, sizeof(struct lp8788_ldo), GFP_KERNEL);
if (!ldo)
return -ENOMEM;
@@ -777,7 +777,7 @@ static int lp8788_aldo_probe(struct platform_device *pdev)
if (ret)
return ret;
- cfg.dev = lp->dev;
+ cfg.dev = pdev->dev.parent;
cfg.init_data = lp->pdata ? lp->pdata->aldo_data[id] : NULL;
cfg.driver_data = ldo;
cfg.regmap = lp->regmap;
@@ -785,7 +785,7 @@ static int lp8788_aldo_probe(struct platform_device *pdev)
rdev = regulator_register(&lp8788_aldo_desc[id], &cfg);
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
- dev_err(lp->dev, "ALDO%d regulator register err = %d\n",
+ dev_err(&pdev->dev, "ALDO%d regulator register err = %d\n",
id + 1, ret);
return ret;
}
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] lp8788-buck: fix a for-loop coding style
Remove space before semicolon in for-loop.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-buck.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/lp8788-buck.c b/drivers/regulator/lp8788-buck.c
index 98770e8..1161949 100644
--- a/drivers/regulator/lp8788-buck.c
+++ b/drivers/regulator/lp8788-buck.c
@@ -449,7 +449,7 @@ static int lp8788_dvs_gpio_request(struct platform_device
*pdev,
buck->dvs = pdata->buck1_dvs;
break;
case BUCK2:
- for (i = 0 ; i < LP8788_NUM_BUCK2_DVS ; i++) {
+ for (i = 0; i < LP8788_NUM_BUCK2_DVS; i++) {
gpio = pdata->buck2_dvs->gpio[i];
ret = devm_gpio_request_one(&pdev->dev, gpio,
DVS_LOW, b2_name[i]);
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] lp8788-buck: fix a parent device on devm_gpio_request()
Use 'platform_device' rather than i2c client device node.
Arguments are added in lp8788_init_dvs() and lp8788_dvs_gpio_request().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-buck.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/lp8788-buck.c b/drivers/regulator/lp8788-buck.c
index 4916a55..98770e8 100644
--- a/drivers/regulator/lp8788-buck.c
+++ b/drivers/regulator/lp8788-buck.c
@@ -429,7 +429,8 @@ static struct regulator_desc lp8788_buck_desc[] = {
},
};
-static int lp8788_dvs_gpio_request(struct lp8788_buck *buck,
+static int lp8788_dvs_gpio_request(struct platform_device *pdev,
+ struct lp8788_buck *buck,
enum lp8788_buck_id id)
{
struct lp8788_platform_data *pdata = buck->lp->pdata;
@@ -440,7 +441,7 @@ static int lp8788_dvs_gpio_request(struct lp8788_buck *buck,
switch (id) {
case BUCK1:
gpio = pdata->buck1_dvs->gpio;
- ret = devm_gpio_request_one(buck->lp->dev, gpio, DVS_LOW,
+ ret = devm_gpio_request_one(&pdev->dev, gpio, DVS_LOW,
b1_name);
if (ret)
return ret;
@@ -450,7 +451,7 @@ static int lp8788_dvs_gpio_request(struct lp8788_buck *buck,
case BUCK2:
for (i = 0 ; i < LP8788_NUM_BUCK2_DVS ; i++) {
gpio = pdata->buck2_dvs->gpio[i];
- ret = devm_gpio_request_one(buck->lp->dev, gpio,
+ ret = devm_gpio_request_one(&pdev->dev, gpio,
DVS_LOW, b2_name[i]);
if (ret)
return ret;
@@ -464,7 +465,8 @@ static int lp8788_dvs_gpio_request(struct lp8788_buck *buck,
return 0;
}
-static int lp8788_init_dvs(struct lp8788_buck *buck, enum lp8788_buck_id id)
+static int lp8788_init_dvs(struct platform_device *pdev,
+ struct lp8788_buck *buck, enum lp8788_buck_id id)
{
struct lp8788_platform_data *pdata = buck->lp->pdata;
u8 mask[] = { LP8788_BUCK1_DVS_SEL_M, LP8788_BUCK2_DVS_SEL_M };
@@ -483,7 +485,7 @@ static int lp8788_init_dvs(struct lp8788_buck *buck, enum
lp8788_buck_id id)
(id == BUCK2 && !pdata->buck2_dvs))
goto set_default_dvs_mode;
- if (lp8788_dvs_gpio_request(buck, id))
+ if (lp8788_dvs_gpio_request(pdev, buck, id))
goto set_default_dvs_mode;
return lp8788_update_bits(buck->lp, LP8788_BUCK_DVS_SEL, mask[id],
@@ -509,7 +511,7 @@ static int lp8788_buck_probe(struct platform_device *pdev)
buck->lp = lp;
- ret = lp8788_init_dvs(buck, id);
+ ret = lp8788_init_dvs(pdev, buck, id);
if (ret)
return ret;
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] lp8788-buck: fix a parent deivce in _probe()
The lp8788-buck is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc, registering a regulator and device kernel message.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-buck.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/lp8788-buck.c b/drivers/regulator/lp8788-buck.c
index aef3f2b..4916a55 100644
--- a/drivers/regulator/lp8788-buck.c
+++ b/drivers/regulator/lp8788-buck.c
@@ -503,7 +503,7 @@ static int lp8788_buck_probe(struct platform_device *pdev)
struct regulator_dev *rdev;
int ret;
- buck = devm_kzalloc(lp->dev, sizeof(struct lp8788_buck), GFP_KERNEL);
+ buck = devm_kzalloc(&pdev->dev, sizeof(struct lp8788_buck), GFP_KERNEL);
if (!buck)
return -ENOMEM;
@@ -513,7 +513,7 @@ static int lp8788_buck_probe(struct platform_device *pdev)
if (ret)
return ret;
- cfg.dev = lp->dev;
+ cfg.dev = pdev->dev.parent;
cfg.init_data = lp->pdata ? lp->pdata->buck_data[id] : NULL;
cfg.driver_data = buck;
cfg.regmap = lp->regmap;
@@ -521,7 +521,7 @@ static int lp8788_buck_probe(struct platform_device *pdev)
rdev = regulator_register(&lp8788_buck_desc[id], &cfg);
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
- dev_err(lp->dev, "BUCK%d regulator register err = %d\n",
+ dev_err(&pdev->dev, "BUCK%d regulator register err = %d\n",
id + 1, ret);
return ret;
}
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] lp8788-charger: fix a parent device in _probe()
The lp8788-charger is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc and device kernel message.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/power/lp8788-charger.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/power/lp8788-charger.c b/drivers/power/lp8788-charger.c
index 22b6407..126a83a 100644
--- a/drivers/power/lp8788-charger.c
+++ b/drivers/power/lp8788-charger.c
@@ -690,9 +690,10 @@ static int lp8788_charger_probe(struct platform_device
*pdev)
{
struct lp8788 *lp = dev_get_drvdata(pdev->dev.parent);
struct lp8788_charger *pchg;
+ struct device *dev = &pdev->dev;
int ret;
- pchg = devm_kzalloc(lp->dev, sizeof(struct lp8788_charger), GFP_KERNEL);
+ pchg = devm_kzalloc(dev, sizeof(struct lp8788_charger), GFP_KERNEL);
if (!pchg)
return -ENOMEM;
@@ -718,7 +719,7 @@ static int lp8788_charger_probe(struct platform_device
*pdev)
ret = lp8788_irq_register(pdev, pchg);
if (ret)
- dev_warn(lp->dev, "failed to register charger irq: %d\n", ret);
+ dev_warn(dev, "failed to register charger irq: %d\n", ret);
return 0;
}
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] lp8788-charger: fix a parent device in kernel messages
Use 'platform_device' in kernel messages rather than i2c client
device node.
lp8788_update_charger_params() needs additional argument, 'pdev'.
Then, remove unnecessary lp8788 private data in lp8788_irq_register().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/power/lp8788-charger.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/power/lp8788-charger.c b/drivers/power/lp8788-charger.c
index 126a83a..e33d6b2 100644
--- a/drivers/power/lp8788-charger.c
+++ b/drivers/power/lp8788-charger.c
@@ -367,7 +367,8 @@ static inline bool lp8788_is_valid_charger_register(u8 addr)
return addr >= LP8788_CHG_START && addr <= LP8788_CHG_END;
}
-static int lp8788_update_charger_params(struct lp8788_charger *pchg)
+static int lp8788_update_charger_params(struct platform_device *pdev,
+ struct lp8788_charger *pchg)
{
struct lp8788 *lp = pchg->lp;
struct lp8788_charger_platform_data *pdata = pchg->pdata;
@@ -376,7 +377,7 @@ static int lp8788_update_charger_params(struct
lp8788_charger *pchg)
int ret;
if (!pdata || !pdata->chg_params) {
- dev_info(lp->dev, "skip updating charger parameters\n");
+ dev_info(&pdev->dev, "skip updating charger parameters\n");
return 0;
}
@@ -537,7 +538,6 @@ err_free_irq:
static int lp8788_irq_register(struct platform_device *pdev,
struct lp8788_charger *pchg)
{
- struct lp8788 *lp = pchg->lp;
const char *name[] = {
LP8788_CHG_IRQ, LP8788_PRSW_IRQ, LP8788_BATT_IRQ
};
@@ -550,13 +550,13 @@ static int lp8788_irq_register(struct platform_device
*pdev,
for (i = 0; i < ARRAY_SIZE(name); i++) {
ret = lp8788_set_irqs(pdev, pchg, name[i]);
if (ret) {
- dev_warn(lp->dev, "irq setup failed: %s\n", name[i]);
+ dev_warn(&pdev->dev, "irq setup failed: %s\n", name[i]);
return ret;
}
}
if (pchg->num_irqs > LP8788_MAX_CHG_IRQS) {
- dev_err(lp->dev, "invalid total number of irqs: %d\n",
+ dev_err(&pdev->dev, "invalid total number of irqs: %d\n",
pchg->num_irqs);
return -EINVAL;
}
@@ -701,7 +701,7 @@ static int lp8788_charger_probe(struct platform_device
*pdev)
pchg->pdata = lp->pdata ? lp->pdata->chg_pdata : NULL;
platform_set_drvdata(pdev, pchg);
- ret = lp8788_update_charger_params(pchg);
+ ret = lp8788_update_charger_params(pdev, pchg);
if (ret)
return ret;
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] iio: lp8788_adc: fix parent device in kernel message
Use 'dev' of iio device in a kernel message rather than i2c client device node.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/iio/adc/lp8788_adc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/lp8788_adc.c b/drivers/iio/adc/lp8788_adc.c
index 4c9b0f7..f8bcb1f 100644
--- a/drivers/iio/adc/lp8788_adc.c
+++ b/drivers/iio/adc/lp8788_adc.c
@@ -179,7 +179,7 @@ static int lp8788_iio_map_register(struct iio_dev
*indio_dev,
ret = iio_map_array_register(indio_dev, map);
if (ret) {
- dev_err(adc->lp->dev, "iio map err: %d\n", ret);
+ dev_err(&indio_dev->dev, "iio map err: %d\n", ret);
return ret;
}
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] iio: lp8788_adc: fix a parent device in _probe()
The lp8788-adc is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device of
iio device and device kernel message.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/iio/adc/lp8788_adc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/lp8788_adc.c b/drivers/iio/adc/lp8788_adc.c
index 72955e4..4c9b0f7 100644
--- a/drivers/iio/adc/lp8788_adc.c
+++ b/drivers/iio/adc/lp8788_adc.c
@@ -214,7 +214,7 @@ static int lp8788_adc_probe(struct platform_device *pdev)
mutex_init(&adc->lock);
- indio_dev->dev.parent = lp->dev;
+ indio_dev->dev.parent = &pdev->dev;
indio_dev->name = pdev->name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = &lp8788_adc_info;
@@ -223,7 +223,7 @@ static int lp8788_adc_probe(struct platform_device *pdev)
ret = iio_device_register(indio_dev);
if (ret) {
- dev_err(lp->dev, "iio dev register err: %d\n", ret);
+ dev_err(&pdev->dev, "iio dev register err: %d\n", ret);
goto err_iio_device;
}
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] leds-lp8788: fix a parent device in _probe()
The lp8788-keyled is a platform driver of lp8788-mfd.
The platform device is allocated when mfd_add_devices() is called
in lp8788-mfd.
On the other hand, 'lp->dev' is the i2c client device.
Therefore, this 'platform_device' is a proper parent device in case of
resource managed mem alloc, registering led device and device kernel messages.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/leds-lp8788.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/leds-lp8788.c b/drivers/leds/leds-lp8788.c
index 4353942..7c2cb38 100644
--- a/drivers/leds/leds-lp8788.c
+++ b/drivers/leds/leds-lp8788.c
@@ -130,9 +130,10 @@ static int lp8788_led_probe(struct platform_device *pdev)
struct lp8788 *lp = dev_get_drvdata(pdev->dev.parent);
struct lp8788_led_platform_data *led_pdata;
struct lp8788_led *led;
+ struct device *dev = &pdev->dev;
int ret;
- led = devm_kzalloc(lp->dev, sizeof(struct lp8788_led), GFP_KERNEL);
+ led = devm_kzalloc(dev, sizeof(struct lp8788_led), GFP_KERNEL);
if (!led)
return -ENOMEM;
@@ -154,13 +155,13 @@ static int lp8788_led_probe(struct platform_device *pdev)
ret = lp8788_led_init_device(led, led_pdata);
if (ret) {
- dev_err(lp->dev, "led init device err: %d\n", ret);
+ dev_err(dev, "led init device err: %d\n", ret);
return ret;
}
- ret = led_classdev_register(lp->dev, &led->led_dev);
+ ret = led_classdev_register(dev, &led->led_dev);
if (ret) {
- dev_err(lp->dev, "led register err: %d\n", ret);
+ dev_err(dev, "led register err: %d\n", ret);
return ret;
}
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] mm: introduce VM_POPULATE flag to better deal with racy userspace programs
On 12/20/2012 07:49 PM, Michel Lespinasse wrote: The vm_populate() code populates user mappings without constantly holding the mmap_sem. This makes it susceptible to racy userspace programs: the user mappings may change while vm_populate() is running, and in this case vm_populate() may end up populating the new mapping instead of the old one. In order to reduce the possibility of userspace getting surprised by this behavior, this change introduces the VM_POPULATE vma flag which gets set on vmas we want vm_populate() to work on. This way vm_populate() may still end up populating the new mapping after such a race, but only if the new mapping is also one that the user has requested (using MAP_SHARED, MAP_LOCKED or mlock) to be populated. Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/9] mm: make do_mmap_pgoff return populate as a size in bytes, not as a bool
On 12/22/2012 04:45 AM, Michel Lespinasse wrote: do_mmap_pgoff() rounds up the desired size to the next PAGE_SIZE multiple, however there was no equivalent code in mm_populate(), which caused issues. This could be fixed by introduced the same rounding in mm_populate(), however I think it's preferable to make do_mmap_pgoff() return populate as a size rather than as a boolean, so we don't have to duplicate the size rounding logic in mm_populate(). Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] rtc: add RTC driver for TPS6586x
On Thursday 03 January 2013 05:20 AM, Andrew Morton wrote: On Thu, 27 Dec 2012 20:29:14 +0530 Laxman Dewangan wrote: On Thursday 27 December 2012 08:26 PM, Marc Dietrich wrote: Hi Laxman, On Friday 21 December 2012 20:42:28 you wrote: + + /* Set epoch start as 00:00:00:01:01:2000 */ + rtc->epoch_start = mktime(2000, 1, 1, 0, 0, 0); any reason why you hard coded it to 2000? All boards I know use 2009, so with this patch, everyone needs to set his clock again. No specific reason. If 2009 should be default then I can push patch to set it as 2009. I'd like to get this into Linus soon so let's get it finished. I assume it's merely this? Yes, the following change is only require. I was waiting for driver to be avilable on linux-next before sending patch to avoid any conflict. Thanks a lot for taking care. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] Please pull powerpc.git merge branch
On Thu, 2013-01-03 at 17:13 +1100, Benjamin Herrenschmidt wrote: > Hi Linus ! > > Here are a couple of small powerpc fixes. They aren't new bugs (and > they are both CCed to stable) but I didn't see the point of sitting > on the fixes any longer. Looks like I still need to fix my script to get the branch name right for when the mirrors haven't caught up... It's git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a couple of small powerpc fixes. They aren't new bugs (and they are both CCed to stable) but I didn't see the point of sitting on the fixes any longer. Oh and happy new year ! Cheers, Ben. The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git for you to fetch changes up to e6449c9b2d90c1bd9a5985bf05ddebfd1631cd6b: powerpc: Add missing NULL terminator to avoid boot panic on PPC40x (2013-01-03 16:45:52 +1100) Gabor Juhos (1): powerpc: Add missing NULL terminator to avoid boot panic on PPC40x Shan Hai (1): powerpc/vdso: Remove redundant locking in update_vsyscall_tz() arch/powerpc/kernel/time.c |5 - arch/powerpc/platforms/40x/ppc40x_simple.c |3 ++- 2 files changed, 2 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/11] ARM: dt: tegra30: Add device node for APB MISC
On Thursday 03 January 2013 03:30 AM, Stephen Warren wrote: On 12/27/2012 07:47 AM, Prashant Gaikwad wrote: APB misc contains multiple registers required by different modules such as CAR. I don't see a DT binding document that describes what nvidia,tegra30-apbmisc means. Also, the register range for this new node overlaps that for the pinmux node, so they can't both "request" their register region. You may need multiple entries in the apbmisc reg property to avoid this. apbmisc reg for Tegra30 can be divided into following entries: strap registers jtag configuration registers pull_up/pull_down control registers vclk control registers tvdac registers chip id revision registers pad control registers This list is not same for Tegra20 and Tegra30. OR another way is to add chip id revision register region to CAR node as done for pinmux node and remove apb misc node. What is preferred? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/8] Support for Tegra 2D hardware
On 21.12.2012 15:50, Lucas Stach wrote:
> Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
>> Some of the issues left open:
>> * Register definitions still use static inline. There has been a
>>debate about code style versus ability to use compiler type
>>checking and code coverage analysis. There was no conclusion, so
>>I left it as was.
> This has to be resolved before merging. Personally I'm in favour of
> keeping reg access patterns close to what is done in other parts of the
> kernel.
How about if I define inline functions, and #defines to proxy to them?
Something like:
static inline u32 host1x_sync_cfpeek_ctrl_r(void)
{
return 0x74c;
}
#define HOST1X_SYNC_CFPEEK_CTRL \
host1x_sync_cfpeek_ctrl_r()
static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_ena_f(u32 v)
{
return (v & 0x1) << 31;
}
#define HOST1X_SYNC_CFPEEK_CTRL_CFPEEK_ENA_F(v) \
host1x_sync_cfpeek_ctrl_cfpeek_ena_f(v)
I'd use the macros in .c files. That way the references will look
familiar to reader of .c files, but we can still get the benefits of
compiler processing (type checking, better error codes etc) and gcov
coverage tracking.
Terje
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/8] Support for Tegra 2D hardware
On 01/03/2013 01:50 PM, Terje Bergström wrote: > On 03.01.2013 05:31, Mark Zhang wrote: >> Sorry I didn't get it. Yes, in current design, you can pin all mem >> handles in one time but I haven't found anything related with "locking >> only once per submit". >> >> My idea is: >> - remove "job->addr_phys" >> - assign "job->reloc_addr_phys" & "job->gather_addr_phys" separately >> - In "pin_job_mem", just call "host1x_memmgr_pin_array_ids" twice to >> fill the "reloc_addr_phy" & "gather_addr_phys". >> >> Anything I misunderstood? > > The current design uses CMA, which makes pinning basically a no-op. When > we have IOMMU support, pinning requires calling into IOMMU. Updating > SMMU tables requires locking, and probably maintenance before SMMU code > also requires its own locked data tables. For example, preventing > duplicate pinning might require a global table of handles. > > Putting all of the handles in one table allows doing duplicate detection > across cmdbuf and reloc tables. This allows pinning each buffer exactly > once, which reduces number of calls to IOMMU. > Thanks Terje. Yes, I understand IOMMU will bring in more operations. But I'm not convinced that separating 2 arrays have lots of overheads than putting them into one array. But it doesn't matter, after the IOMMU support version released, I can read this part of codes again. Let's talk about this at that time. >> "host1x_cma_pin_array_ids" doesn't return negative value right now, so >> maybe you need to take a look at it. > > True, and also a consequence of using CMA: pinning can never fail. With > IOMMU, pinning can fail. Got it. Agree. > > Terje > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] mm: directly use __mlock_vma_pages_range() in find_extend_vma()
On 12/20/2012 07:49 PM, Michel Lespinasse wrote: In find_extend_vma(), we don't need mlock_vma_pages_range() to verify the vma type - we know we're working with a stack. So, we can call directly into __mlock_vma_pages_range(), and remove the last make_pages_present() call site. Note that we don't use mm_populate() here, so we can't release the mmap_sem while allocating new stack pages. This is deemed acceptable, because the stack vmas grow by a bounded number of pages at a time, and these are anon pages so we don't have to read from disk to populate them. Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] mm: remove flags argument to mmap_region
On 12/20/2012 07:49 PM, Michel Lespinasse wrote: After the MAP_POPULATE handling has been moved to mmap_region() call sites, the only remaining use of the flags argument is to pass the MAP_NORESERVE flag. This can be just as easily handled by do_mmap_pgoff(), so do that and remove the mmap_region() flags parameter. Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] mm: use mm_populate() for mremap() of VM_LOCKED vmas
On 12/20/2012 07:49 PM, Michel Lespinasse wrote: Signed-off-by: Michel Lespinasse Changelog? Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/8] Support for Tegra 2D hardware
On 03.01.2013 05:31, Mark Zhang wrote: > Sorry I didn't get it. Yes, in current design, you can pin all mem > handles in one time but I haven't found anything related with "locking > only once per submit". > > My idea is: > - remove "job->addr_phys" > - assign "job->reloc_addr_phys" & "job->gather_addr_phys" separately > - In "pin_job_mem", just call "host1x_memmgr_pin_array_ids" twice to > fill the "reloc_addr_phy" & "gather_addr_phys". > > Anything I misunderstood? The current design uses CMA, which makes pinning basically a no-op. When we have IOMMU support, pinning requires calling into IOMMU. Updating SMMU tables requires locking, and probably maintenance before SMMU code also requires its own locked data tables. For example, preventing duplicate pinning might require a global table of handles. Putting all of the handles in one table allows doing duplicate detection across cmdbuf and reloc tables. This allows pinning each buffer exactly once, which reduces number of calls to IOMMU. > "host1x_cma_pin_array_ids" doesn't return negative value right now, so > maybe you need to take a look at it. True, and also a consequence of using CMA: pinning can never fail. With IOMMU, pinning can fail. Terje -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/5] x86,smp: make ticket spinlock proportional backoff w/ auto tuning
Many spinlocks are embedded in data structures; having many CPUs pounce on the cache line the lock is in will slow down the lock holder, and can cause system performance to fall off a cliff. The paper "Non-scalable locks are dangerous" is a good reference: http://pdos.csail.mit.edu/papers/linux:lock.pdf In the Linux kernel, spinlocks are optimized for the case of there not being contention. After all, if there is contention, the data structure can be improved to reduce or eliminate lock contention. Likewise, the spinlock API should remain simple, and the common case of the lock not being contended should remain as fast as ever. However, since spinlock contention should be fairly uncommon, we can add functionality into the spinlock slow path that keeps system performance from falling off a cliff when there is lock contention. Proportional delay in ticket locks is delaying the time between checking the ticket based on a delay factor, and the number of CPUs ahead of us in the queue for this lock. Checking the lock less often allows the lock holder to continue running, resulting in better throughput and preventing performance from dropping off a cliff. The test case has a number of threads locking and unlocking a semaphore. With just one thread, everything sits in the CPU cache and throughput is around 2.6 million operations per second, with a 5-10% variation. Once a second thread gets involved, data structures bounce from CPU to CPU, and performance deteriorates to about 1.25 million operations per second, with a 5-10% variation. However, as more and more threads get added to the mix, performance with the vanilla kernel continues to deteriorate. Once I hit 24 threads, on a 24 CPU, 4 node test system, performance is down to about 290k operations/second. With a proportional backoff delay added to the spinlock code, performance with 24 threads goes up to about 400k operations/second with a 50x delay, and about 900k operations/second with a 250x delay. However, with a 250x delay, performance with 2-5 threads is worse than with a 50x delay. Making the code auto-tune the delay factor results in a system that performs well with both light and heavy lock contention, and should also protect against the (likely) case of the fixed delay factor being wrong for other hardware. The attached graph shows the performance of the multi threaded semaphore lock/unlock test case, with 1-24 threads, on the vanilla kernel, with 10x, 50x, and 250x proportional delay, as well as the v1 patch series with autotuning for 2x and 2.7x spinning before the lock is obtained, and with the v2 series. The v2 series integrates several ideas from Michel Lespinasse and Eric Dumazet, which should result in better throughput and nicer behaviour in situations with contention on multiple locks. Please let me know if you manage to break this code in any way, so I can fix it... -- All rights reversed. <>
[RFC PATCH 3/5] x86,smp: auto tune spinlock backoff delay factor
Many spinlocks are embedded in data structures; having many CPUs
pounce on the cache line the lock is in will slow down the lock
holder, and can cause system performance to fall off a cliff.
The paper "Non-scalable locks are dangerous" is a good reference:
http://pdos.csail.mit.edu/papers/linux:lock.pdf
In the Linux kernel, spinlocks are optimized for the case of
there not being contention. After all, if there is contention,
the data structure can be improved to reduce or eliminate
lock contention.
Likewise, the spinlock API should remain simple, and the
common case of the lock not being contended should remain
as fast as ever.
However, since spinlock contention should be fairly uncommon,
we can add functionality into the spinlock slow path that keeps
system performance from falling off a cliff when there is lock
contention.
Proportional delay in ticket locks is delaying the time between
checking the ticket based on a delay factor, and the number of
CPUs ahead of us in the queue for this lock. Checking the lock
less often allows the lock holder to continue running, resulting
in better throughput and preventing performance from dropping
off a cliff.
Proportional spinlock delay with a high delay factor works well
when there is lots contention on a lock. Likewise, a smaller
delay factor works well when a lock is lightly contended.
Making the code auto-tune the delay factor results in a system
that performs well with both light and heavy lock contention.
Signed-off-by: Rik van Riel
---
arch/x86/kernel/smp.c | 41 ++---
1 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index aa743e9..f1ec7f7 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -113,12 +113,31 @@ static atomic_t stopping_cpu = ATOMIC_INIT(-1);
static bool smp_no_nmi_ipi = false;
/*
- * Wait on a congested ticket spinlock.
+ * Wait on a congested ticket spinlock. Many spinlocks are embedded in
+ * data structures; having many CPUs pounce on the cache line with the
+ * spinlock simultaneously can slow down the lock holder, and the system
+ * as a whole.
+ *
+ * To prevent total performance collapse in case of bad spinlock contention,
+ * perform proportional backoff. The per-cpu value of delay is automatically
+ * tuned to limit the number of times spinning CPUs poll the lock before
+ * obtaining it. This limits the amount of cross-CPU traffic required to obtain
+ * a spinlock, and keeps system performance from dropping off a cliff.
+ *
+ * There is a tradeoff. If we poll too often, the whole system is slowed
+ * down. If we sleep too long, the lock will go unused for a period of
+ * time. The solution is to go for a fast spin if we are at the head of
+ * the queue, to slowly increase the delay if we sleep for too short a
+ * time, and to decrease the delay if we slept for too long.
*/
+#define MIN_SPINLOCK_DELAY 1
+#define MAX_SPINLOCK_DELAY 16000
+DEFINE_PER_CPU(int, spinlock_delay) = { MIN_SPINLOCK_DELAY };
void ticket_spin_lock_wait(arch_spinlock_t *lock, struct __raw_tickets inc)
{
__ticket_t head = inc.head, ticket = inc.tail;
__ticket_t waiters_ahead;
+ int delay = __this_cpu_read(spinlock_delay);
unsigned loops;
for (;;) {
@@ -133,14 +152,30 @@ void ticket_spin_lock_wait(arch_spinlock_t *lock, struct
__raw_tickets inc)
} while (ACCESS_ONCE(lock->tickets.head) != ticket);
break;
}
- loops = 50 * waiters_ahead;
+
+ /*
+* The lock is still busy; slowly increase the delay. If we
+* end up sleeping too long, the code below will reduce the
+* delay. Ideally we acquire the lock in the tight loop above.
+*/
+ if (!(head % 7) && delay < MAX_SPINLOCK_DELAY)
+ delay++;
+
+ loops = delay * waiters_ahead;
while (loops--)
cpu_relax();
head = ACCESS_ONCE(lock->tickets.head);
- if (head == ticket)
+ if (head == ticket) {
+ /*
+* We overslept and have no idea how long the lock
+* went idle. Reduce the delay as a precaution.
+*/
+ delay -= delay/32 + 1;
break;
+ }
}
+ __this_cpu_write(spinlock_delay, delay);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/5] x86,smp: proportional backoff for ticket spinlocks
Simple fixed value proportional backoff for ticket spinlocks.
By pounding on the cacheline with the spin lock less often,
bus traffic is reduced. In cases of a data structure with
embedded spinlock, the lock holder has a better chance of
making progress.
If we are next in line behind the current holder of the
lock, we do a fast spin, so as not to waste any time when
the lock is released.
The number 50 is likely to be wrong for many setups, and
this patch is mostly to illustrate the concept of proportional
backup. The next patch automatically tunes the delay value.
Signed-off-by: Rik van Riel
Signed-off-by: Michel Lespinasse
---
arch/x86/kernel/smp.c | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 20da354..9c56fe3 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -117,11 +117,28 @@ static bool smp_no_nmi_ipi = false;
*/
void ticket_spin_lock_wait(arch_spinlock_t *lock, struct __raw_tickets inc)
{
+ __ticket_t head = inc.head, ticket = inc.tail;
+ __ticket_t waiters_ahead;
+ unsigned loops;
+
for (;;) {
- cpu_relax();
- inc.head = ACCESS_ONCE(lock->tickets.head);
+ waiters_ahead = ticket - head - 1;
+ /*
+* We are next after the current lock holder. Check often
+* to avoid wasting time when the lock is released.
+*/
+ if (!waiters_ahead) {
+ do {
+ cpu_relax();
+ } while (ACCESS_ONCE(lock->tickets.head) != ticket);
+ break;
+ }
+ loops = 50 * waiters_ahead;
+ while (loops--)
+ cpu_relax();
- if (inc.head == inc.tail)
+ head = ACCESS_ONCE(lock->tickets.head);
+ if (head == ticket)
break;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/5] x86,smp: move waiting on contended ticket lock out of line
Moving the wait loop for congested loops to its own function allows
us to add things to that wait loop, without growing the size of the
kernel text appreciably.
Signed-off-by: Rik van Riel
Reviewed-by: Steven Rostedt
Reviewed-by: Michel Lespinasse
Reviewed-by: Rafael Aquini
---
v2: clean up the code a little, after Michel's suggestion
arch/x86/include/asm/spinlock.h | 11 +--
arch/x86/kernel/smp.c | 14 ++
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
index 33692ea..dc492f6 100644
--- a/arch/x86/include/asm/spinlock.h
+++ b/arch/x86/include/asm/spinlock.h
@@ -34,6 +34,8 @@
# define UNLOCK_LOCK_PREFIX
#endif
+extern void ticket_spin_lock_wait(arch_spinlock_t *, struct __raw_tickets);
+
/*
* Ticket locks are conceptually two parts, one indicating the current head of
* the queue, and the other indicating the current tail. The lock is acquired
@@ -53,12 +55,9 @@ static __always_inline void
__ticket_spin_lock(arch_spinlock_t *lock)
inc = xadd(&lock->tickets, inc);
- for (;;) {
- if (inc.head == inc.tail)
- break;
- cpu_relax();
- inc.head = ACCESS_ONCE(lock->tickets.head);
- }
+ if (inc.head != inc.tail)
+ ticket_spin_lock_wait(lock, inc);
+
barrier(); /* make sure nothing creeps before the lock is
taken */
}
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 48d2b7d..20da354 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -113,6 +113,20 @@ static atomic_t stopping_cpu = ATOMIC_INIT(-1);
static bool smp_no_nmi_ipi = false;
/*
+ * Wait on a congested ticket spinlock.
+ */
+void ticket_spin_lock_wait(arch_spinlock_t *lock, struct __raw_tickets inc)
+{
+ for (;;) {
+ cpu_relax();
+ inc.head = ACCESS_ONCE(lock->tickets.head);
+
+ if (inc.head == inc.tail)
+ break;
+ }
+}
+
+/*
* this function sends a 'reschedule' IPI to another CPU.
* it goes straight through and wastes no time serializing
* anything. Worst case is that we lose a reschedule ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 5/5] x86,smp: add debugging code to track spinlock delay value
From: Eric Dumazet
This code prints out the maximum spinlock delay value and the
backtrace that pushed it that far.
On systems with serial consoles, the act of printing can cause
the spinlock delay value to explode. It can still be useful as
a debugging tool, but is probably too verbose to merge upstream
in this form.
Not-signed-off-by: Rik van Riel
Not-signed-off-by: Eric Dumazet
---
arch/x86/kernel/smp.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 29360c4..a4401ed 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -148,6 +148,8 @@ static DEFINE_PER_CPU(struct delay_entry [1 <<
DELAY_HASH_SHIFT], spinlock_delay
},
};
+static DEFINE_PER_CPU(u16, maxdelay);
+
void ticket_spin_lock_wait(arch_spinlock_t *lock, struct __raw_tickets inc)
{
__ticket_t head = inc.head, ticket = inc.tail;
@@ -195,6 +197,12 @@ void ticket_spin_lock_wait(arch_spinlock_t *lock, struct
__raw_tickets inc)
}
ent->hash = hash;
ent->delay = delay;
+
+ if (__this_cpu_read(maxdelay) < delay) {
+ pr_err("cpu %d lock %p delay %d\n", smp_processor_id(), lock,
delay);
+ __this_cpu_write(maxdelay, delay);
+ WARN_ON(1);
+ }
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 4/5] x86,smp: keep spinlock delay values per hashed spinlock address
From: Eric Dumazet
Eric Dumazet found a regression with the spinlock backoff code,
in workloads where multiple spinlocks were contended, each having
a different wait time.
This patch has multiple delay values per cpu, indexed on a hash
of the lock address, to avoid that problem.
Eric Dumazet wrote:
I did some tests with your patches with following configuration :
tc qdisc add dev eth0 root htb r2q 1000 default 3
(to force a contention on qdisc lock, even with a multi queue net
device)
and 24 concurrent "netperf -t UDP_STREAM -H other_machine -- -m 128"
Machine : 2 Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
(24 threads), and a fast NIC (10Gbps)
Resulting in a 13 % regression (676 Mbits -> 595 Mbits)
In this workload we have at least two contended spinlocks, with
different delays. (spinlocks are not held for the same duration)
It clearly defeats your assumption of a single per cpu delay being OK :
Some cpus are spinning too long while the lock was released.
We might try to use a hash on lock address, and an array of 16 different
delays so that different spinlocks have a chance of not sharing the same
delay.
With following patch, I get 982 Mbits/s with same bench, so an increase
of 45 % instead of a 13 % regression.
Signed-off-by: Eric Dumazet
Signed-off-by: Rik van Riel
---
arch/x86/kernel/smp.c | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 6065291..29360c4 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -135,12 +136,26 @@ static bool smp_no_nmi_ipi = false;
*/
#define MIN_SPINLOCK_DELAY 1
#define MAX_SPINLOCK_DELAY 16000
-DEFINE_PER_CPU(int, spinlock_delay) = { MIN_SPINLOCK_DELAY };
+#define DELAY_HASH_SHIFT 6
+struct delay_entry {
+ u32 hash;
+ u32 delay;
+};
+static DEFINE_PER_CPU(struct delay_entry [1 << DELAY_HASH_SHIFT],
spinlock_delay) = {
+ [0 ... (1 << DELAY_HASH_SHIFT) - 1] = {
+ .hash = 0,
+ .delay = MIN_SPINLOCK_DELAY,
+ },
+};
+
void ticket_spin_lock_wait(arch_spinlock_t *lock, struct __raw_tickets inc)
{
__ticket_t head = inc.head, ticket = inc.tail;
__ticket_t waiters_ahead;
- int delay = __this_cpu_read(spinlock_delay);
+ u32 hash = hash32_ptr(lock);
+ u32 slot = hash_32(hash, DELAY_HASH_SHIFT);
+ struct delay_entry *ent = &__get_cpu_var(spinlock_delay[slot]);
+ u32 delay = (ent->hash == hash) ? ent->delay : MIN_SPINLOCK_DELAY;
unsigned loops;
for (;;) {
@@ -178,7 +193,8 @@ void ticket_spin_lock_wait(arch_spinlock_t *lock, struct
__raw_tickets inc)
break;
}
}
- __this_cpu_write(spinlock_delay, delay);
+ ent->hash = hash;
+ ent->delay = delay;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
Hi Joerg, It's been a while since I submitted this patch. I have tried to address your comments regarding the subwindow attribute. I would really appreciate if I can get some feedback on this patch. Regards Varun > -Original Message- > From: Sethi Varun-B16395 > Sent: Friday, December 21, 2012 7:17 AM > To: 'Joerg Roedel' > Cc: Sethi Varun-B16395; joerg.roe...@amd.com; iommu@lists.linux- > foundation.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; Tabi Timur-B04825; Wood Scott-B07421 > Subject: RE: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API > implementation. > > ping!! > > > -Original Message- > > From: Sethi Varun-B16395 > > Sent: Friday, December 14, 2012 7:22 PM > > To: joerg.roe...@amd.com; io...@lists.linux-foundation.org; linuxppc- > > d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Tabi Timur-B04825; > > Wood Scott-B07421 > > Cc: Sethi Varun-B16395 > > Subject: [PATCH 0/4] iommu/fsl: Freescale PAMU driver and IOMMU API > > implementation. > > > > This patchset provides the Freescale PAMU (Peripheral Access > > Management > > Unit) driver and the corresponding IOMMU API implementation. PAMU is > > the IOMMU present on Freescale QorIQ platforms. PAMU can authorize > > memory access, remap the memory address, and remap the I/O transaction > type. > > > > This set consists of the following patches: > > 1. Addition of new field in the device (powerpc) archdata structure > > for storing iommu domain information > >pointer. This pointer is stored when the device is attached to a > > particular iommu domain. > > 2. Add PAMU bypass enable register to the ccsr_guts structure. > > 3. Addition of domain attributes required by the PAMU driver IOMMU API. > > 4. PAMU driver and IOMMU API implementation. > > > > This patch set is based on the next branch of the iommu git tree > > maintained by Joerg. > > > > Varun Sethi (4): > > store iommu domain info in device arch data. > > add pamu bypass enable register to guts. > > Add iommu attributes for PAMU > > FSL PAMU driver. > > > > arch/powerpc/include/asm/device.h |4 + > > arch/powerpc/include/asm/fsl_guts.h |4 +- > > drivers/iommu/Kconfig |8 + > > drivers/iommu/Makefile |1 + > > drivers/iommu/fsl_pamu.c| 1152 > > +++ > > drivers/iommu/fsl_pamu.h| 398 > > drivers/iommu/fsl_pamu_domain.c | 1033 > > +++ > > drivers/iommu/fsl_pamu_domain.h | 96 +++ > > include/linux/iommu.h | 49 ++ > > 9 files changed, 2744 insertions(+), 1 deletions(-) create mode > > 100644 drivers/iommu/fsl_pamu.c create mode 100644 > > drivers/iommu/fsl_pamu.h create mode 100644 > > drivers/iommu/fsl_pamu_domain.c create mode 100644 > > drivers/iommu/fsl_pamu_domain.h > > > > -- > > 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Tue, 1 Jan 2013, Simon Jeons wrote: > > Hi Petr and Hugh, > > One offline question, thanks for your clarify. Perhaps not as offline as you intended :) > > How to understand age = (unsigned char)(ksm_scan.seqnr - > rmap_item->address);? It used for what? As you can see, remove_rmap_item_from_tree uses it to decide whether or not it should rb_erase the rmap_item from the unstable_tree. Every full scan of all the rmap_items, we increment ksm_scan.seqnr, forget the old unstable_tree (it would just be a waste of processing to remove every node one by one), and build up the unstable_tree afresh. That works fine until we need to remove an rmap_item: then we have to be very sure to remove it from the unstable_tree if it's already been linked there during this scan, but ignore its rblinkage if that's just left over from the previous scan. A single bit would be enough to decide this; but we got it troublesomely wrong in the early days of KSM (didn't always visit every rmap_item each scan), so it's convenient to use 8 bits (the low unsigned char, stored below the FLAGs and below the page-aligned address in the rmap_item - there's lots of them, best keep them as small as we can) and do a BUG_ON(age > 1) if we made a mistake. We haven't hit that BUG_ON in over three years: if we need some more bits for something, we can cut the age down to one or two bits. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] irqchip: vt8500: Move irq code to drivers/irqchip
On 01/02/2013 09:25 PM, Tony Prisk wrote:
> Move mach-vt8500/irq.c to drivers/irqchip/irq-vt8500.c and make
> necessary Makefile changes. No code changes required.
>
> Signed-off-by: Tony Prisk
> ---
> CC: Thomas Gleixner
> arch/arm/mach-vt8500/Makefile |2 +-
> arch/arm/mach-vt8500/common.h |7 +-
> arch/arm/mach-vt8500/irq.c| 253
> -
> drivers/irqchip/Makefile |1 +
> drivers/irqchip/irq-vt8500.c | 253
> +
It's easy to forget, but please post using the -M option so only real
changes are shown.
> 5 files changed, 258 insertions(+), 258 deletions(-)
> delete mode 100644 arch/arm/mach-vt8500/irq.c
> create mode 100644 drivers/irqchip/irq-vt8500.c
>
> diff --git a/arch/arm/mach-vt8500/Makefile b/arch/arm/mach-vt8500/Makefile
> index 92ceb24..4c8a846 100644
> --- a/arch/arm/mach-vt8500/Makefile
> +++ b/arch/arm/mach-vt8500/Makefile
> @@ -1 +1 @@
> -obj-$(CONFIG_ARCH_VT8500) += irq.o vt8500.o
> +obj-$(CONFIG_ARCH_VT8500) += vt8500.o
> diff --git a/arch/arm/mach-vt8500/common.h b/arch/arm/mach-vt8500/common.h
> index 5d37a4f..b198a81 100644
> --- a/arch/arm/mach-vt8500/common.h
> +++ b/arch/arm/mach-vt8500/common.h
> @@ -18,13 +18,12 @@
>
> #include
>
> -int __init vt8500_irq_init(struct device_node *node,
> - struct device_node *parent);
> -
> /* defined in drivers/clk/clk-vt8500.c */
> void __init vtwm_clk_init(void __iomem *pmc_base);
>
> -/* defined in irq.c */
> +/* defined in drivers/irqchip/irq.c */
> +int __init vt8500_irq_init(struct device_node *node,
> + struct device_node *parent);
> asmlinkage void vt8500_handle_irq(struct pt_regs *regs);
These should go away with irqchip infrastructure Thomas and I have been
working on. I plan to post updated version in the next day.
Rob
>
> /* defined in drivers/clocksource/vt8500_timer.c */
> diff --git a/arch/arm/mach-vt8500/irq.c b/arch/arm/mach-vt8500/irq.c
> deleted file mode 100644
> index b9cf5ce..000
> --- a/arch/arm/mach-vt8500/irq.c
> +++ /dev/null
> @@ -1,253 +0,0 @@
> -/*
> - * arch/arm/mach-vt8500/irq.c
> - *
> - * Copyright (C) 2012 Tony Prisk
> - * Copyright (C) 2010 Alexey Charkov
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> - */
> -
> -/*
> - * This file is copied and modified from the original irq.c provided by
> - * Alexey Charkov. Minor changes have been made for Device Tree Support.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -
> -#define VT8500_ICPC_IRQ 0x20
> -#define VT8500_ICPC_FIQ 0x24
> -#define VT8500_ICDC 0x40/* Destination Control 64*u32 */
> -#define VT8500_ICIS 0x80/* Interrupt status, 16*u32 */
> -
> -/* ICPC */
> -#define ICPC_MASK0x3F
> -#define ICPC_ROTATE BIT(6)
> -
> -/* IC_DCTR */
> -#define ICDC_IRQ 0x00
> -#define ICDC_FIQ 0x01
> -#define ICDC_DSS00x02
> -#define ICDC_DSS10x03
> -#define ICDC_DSS20x04
> -#define ICDC_DSS30x05
> -#define ICDC_DSS40x06
> -#define ICDC_DSS50x07
> -
> -#define VT8500_INT_DISABLE 0
> -#define VT8500_INT_ENABLEBIT(3)
> -
> -#define VT8500_TRIGGER_HIGH 0
> -#define VT8500_TRIGGER_RISINGBIT(5)
> -#define VT8500_TRIGGER_FALLING BIT(6)
> -#define VT8500_EDGE ( VT8500_TRIGGER_RISING \
> - | VT8500_TRIGGER_FALLING)
> -
> -/* vt8500 has 1 intc, wm8505 and wm8650 have 2 */
> -#define VT8500_INTC_MAX 2
> -
> -struct vt8500_irq_data {
> - void __iomem*base; /* IO Memory base address */
> - struct irq_domain *domain;/* Domain for this controller */
> -};
> -
> -/* Global variable for accessing io-mem addresses */
> -static struct vt8500_irq_data intc[VT8500_INTC_MAX];
> -static u32 active_cnt = 0;
> -
> -static void vt8500_irq_mask(struct irq_data *d)
> -{
> - struct vt8500_irq_data *priv = d->domain->host_data;
> - void __iomem *base = priv->base;
> - void __iomem *stat_reg = base + VT8
Re: [PATCH 2/2] irqchip: vt8500: Move irq code to drivers/irqchip
On Wed, 2013-01-02 at 22:38 -0600, Rob Herring wrote: > > CC: Thomas Gleixner > > arch/arm/mach-vt8500/Makefile |2 +- > > arch/arm/mach-vt8500/common.h |7 +- > > arch/arm/mach-vt8500/irq.c| 253 > > - > > drivers/irqchip/Makefile |1 + > > drivers/irqchip/irq-vt8500.c | 253 > > + > > It's easy to forget, but please post using the -M option so only real > changes are shown. Ok. > > -/* defined in irq.c */ > > +/* defined in drivers/irqchip/irq.c */ > > +int __init vt8500_irq_init(struct device_node *node, > > + struct device_node *parent); > > asmlinkage void vt8500_handle_irq(struct pt_regs *regs); > > These should go away with irqchip infrastructure Thomas and I have been > working on. I plan to post updated version in the next day. > > Rob Do you want me to rebase this patch on the new infrastructure once it's in a tree somewhere, or was this a heads-up that it will need another patch at some point? I only ask because if these patches need to be separated it will created merge-conflicts with arm-soc later on. Regards Tony P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] writeback: fix writeback cache thrashing
2013/1/2, Jan Kara : > On Tue 01-01-13 08:51:04, Wanpeng Li wrote: >> On Mon, Dec 31, 2012 at 12:30:54PM +0100, Jan Kara wrote: >> >On Sun 30-12-12 14:59:50, Namjae Jeon wrote: >> >> From: Namjae Jeon >> >> >> >> Consider Process A: huge I/O on sda >> >> doing heavy write operation - dirty memory becomes more >> >> than dirty_background_ratio >> >> on HDD - flusher thread flush-8:0 >> >> >> >> Consider Process B: small I/O on sdb >> >> doing while [1]; read 1024K + rewrite 1024K + sleep 2sec >> >> on Flash device - flusher thread flush-8:16 >> >> >> >> As Process A is a heavy dirtier, dirty memory becomes more >> >> than dirty_background_thresh. Due to this, below check becomes >> >> true(checking global_page_state in over_bground_thresh) >> >> for all bdi devices(even for very small dirtied bdi - sdb): >> >> >> >> In this case, even small cached data on 'sdb' is forced to flush >> >> and writeback cache thrashing happens. >> >> >> >> When we added debug prints inside above 'if' condition and ran >> >> above Process A(heavy dirtier on bdi with flush-8:0) and >> >> Process B(1024K frequent read/rewrite on bdi with flush-8:16) >> >> we got below prints: >> >> >> >> [Test setup: ARM dual core CPU, 512 MB RAM] >> >> >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56064 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56704 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 384 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 960 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =64 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 256 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 768 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =64 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 256 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 320 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 1024 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =64 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 576 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 512 KB >> >> [over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB >> >> >> >> As mentioned in above log, when global dirty memory > global >> >> background_thresh >> >> small cached data is also forced to flush by flush-8:16. >> >> >> >> If removing global background_thresh checking code, we can reduce >> >> cache >> >> thrashing of frequently used small data. >> > It's not completely clear to me: >> > Why is this a problem? Wearing of the flash? Power consumption? I'd >> > like >> >to understand this before changing the code... Hi Jan. Yes, it can reduce wearing and fragmentation of flash. And also from one scenario - we think it might reduce power consumption also. >> > >> >> And It will be great if we can reserve a portion of writeback cache >> >> using >> >> min_ratio. >> >> >> >> After applying patch: >> >> $ echo 5 > /sys/block/sdb/bdi/min_ratio >> >> $ cat /sys/block/sdb/bdi/min_ratio >> >> 5 >> >> >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56064 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56704 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84160 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 96960 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94080 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93120 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93120 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91520 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 89600 KB >> >> [over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =
[RFC 2/8] Don't allow volatile attribute on THP and KSM
VOLATILE imply the the pages in the range isn't working set any more
so it's pointless that make them to THP/KSM.
Cc: Rik van Riel
Cc: Hugh Dickins
Cc: Andrea Arcangeli
Signed-off-by: Minchan Kim
---
mm/huge_memory.c |9 +++--
mm/ksm.c |3 ++-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 40f17c3..5ddd00e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1477,7 +1477,8 @@ out:
return ret;
}
-#define VM_NO_THP (VM_SPECIAL|VM_MIXEDMAP|VM_HUGETLB|VM_SHARED|VM_MAYSHARE)
+#define VM_NO_THP (VM_SPECIAL|VM_MIXEDMAP|VM_HUGETLB|\
+ VM_SHARED|VM_MAYSHARE|VM_VOLATILE)
int hugepage_madvise(struct vm_area_struct *vma,
unsigned long *vm_flags, int advice)
@@ -1641,6 +1642,8 @@ int khugepaged_enter_vma_merge(struct vm_area_struct *vma)
* page fault if needed.
*/
return 0;
+ if (vma->vm_flags & VM_VOLATILE)
+ return 0;
if (vma->vm_ops)
/* khugepaged not yet working on file or special mappings */
return 0;
@@ -1969,6 +1972,8 @@ static void collapse_huge_page(struct mm_struct *mm,
goto out;
if (is_vma_temporary_stack(vma))
goto out;
+ if (vma->vm_flags & VM_VOLATILE)
+ goto out;
VM_BUG_ON(vma->vm_flags & VM_NO_THP);
pgd = pgd_offset(mm, address);
@@ -2196,7 +2201,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int
pages,
if ((!(vma->vm_flags & VM_HUGEPAGE) &&
!khugepaged_always()) ||
- (vma->vm_flags & VM_NOHUGEPAGE)) {
+(vma->vm_flags & (VM_NOHUGEPAGE|VM_VOLATILE))) {
skip:
progress++;
continue;
diff --git a/mm/ksm.c b/mm/ksm.c
index ae539f0..2775f59 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1486,7 +1486,8 @@ int ksm_madvise(struct vm_area_struct *vma, unsigned long
start,
*/
if (*vm_flags & (VM_MERGEABLE | VM_SHARED | VM_MAYSHARE |
VM_PFNMAP| VM_IO | VM_DONTEXPAND |
-VM_HUGETLB | VM_NONLINEAR | VM_MIXEDMAP))
+VM_HUGETLB | VM_NONLINEAR | VM_MIXEDMAP |
+VM_VOLATILE))
return 0; /* just ignore the advice */
#ifdef VM_SAO
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/8] Introduce new system call mvolatile
This patch adds new system call m[no]volatile. If someone asks is_volatile system call, it could be added, too. The reason why I introduced new system call instead of madvise is m[no]volatile vma handling is totally different with madvise's vma handling. 1) The m[no]volatile should be successful although the range includes unmapped or non-volatile range. It just skips such range without stopping with returning error although it encounters invalid range. It makes user convenient without calling several system call of small range - Suggested by John Stultz 2) The purged state of volatile range should be propagated out to user although the range is merged with adjacent non-volatile range when user calls mnovolatile. 3) mvolatile's interface could be changed with madvise in future discussion. For example, I feel needs movlatile(start, len, mode). 'mode' means FULL_VOLATILE or PARTIAL_VOLATILE. FULL volatile means that if VM decide to reclaim the range, it would reclaim all of pages in the range but in case of PARTIAL_VOLATILE, VM could reclaim just a few number of pages in the range. In case of tmpfs-volatile, user may regenerate all images data once one of page in the range is discarded so there is pointless that VM discard a page in the range when memory pressure is severe. In case of anon-volatile, too excess discarding cause too many minor fault for the allocator so it would be better to discard part of the range. 3) The mvolatile system call's return value is quite different with madvise. Look at below semantic explanation. So I want to separate mvolatile from madvise. mvolatile(start, len)'s semantics 1) It makes range(start, len) as volatile although the range includes unmapped area, speacial mapping and mlocked area which are just skipped. Return -EINVAL if range doesn't include a right vma at all. Return -ENOMEM with interrupting range opeartion if memory is not enough to merge/split vmas. In this case, some ranges would be volatile and others not so user may recall mvolatile after he cancel all range by mnovolatile. Return 0 if range consists of only proper vmas. Return 1 if part of range includes hole/huge/ksm/mlock/special area. 2) If user calls mvolatile to the range which was already volatile VMA and even purged state, VOLATILE attributes still remains but purged state is reset. I expect some user want to split volatile vma into smaller ranges. Although he can do it for mnovlatile(whole range) and serveral calling with movlatile(smaller range), this function can avoid mnovolatile if he doesn't care purged state. I'm not sure we really need this function so I hope listen opinions. Unfortunately, current implemenation doesn't split volatile VMA with new range in this case. I forgot implementing it in this version but decide to send it to listen opinions because implementing is rather trivial if we decided. mnovolatile(start, len)'s semantics is following as. 1) It makes range(start, len) as non-volatile although the range includes unmapped area, speacial mapping and non-volatile range which are just skipped. 2) If the range is purged, it will return 1 regardless of including invalid range. 3) It returns -ENOMEM if system doesn't have enough memory for vma operation. 4) It returns -EINVAL if range doesn't include a right vma at all. 5) If user try to access purged range without mnovoatile call, it encounters SIGBUS which would show up next patch. Cc: Michael Kerrisk Cc: Arun Sharma Cc: san...@google.com Cc: Paul Turner CC: David Rientjes Cc: John Stultz Cc: Andrew Morton Cc: Christoph Lameter Cc: Android Kernel Team Cc: Robert Love Cc: Mel Gorman Cc: Hugh Dickins Cc: Dave Hansen Cc: Rik van Riel Cc: Dave Chinner Cc: Neil Brown Cc: Mike Hommey Cc: Taras Glek Cc: KOSAKI Motohiro Cc: KAMEZAWA Hiroyuki Signed-off-by: Minchan Kim --- arch/x86/syscalls/syscall_64.tbl |2 + fs/exec.c|4 +- include/linux/mm.h |6 +- include/linux/mm_types.h |4 + include/linux/mvolatile.h| 30 include/linux/syscalls.h |2 + mm/Kconfig | 11 ++ mm/Makefile |2 +- mm/madvise.c |2 +- mm/mempolicy.c |2 +- mm/mlock.c |7 +- mm/mmap.c| 62 ++-- mm/mprotect.c|3 +- mm/mremap.c |2 +- mm/mvolatile.c | 312 ++ mm/rmap.c|2 + 16 files changed, 427 insertions(+), 26 deletions(-) create mode 100644 include/linux/mvolatile.h create mode 100644 mm/mvolatile.c diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index a582bfe..568d488 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -319,6 +319,8 @@ 3106
[RFC 5/8] Discard volatile page
VM don't need to swap out volatile pages. Instead, it just discards
pages and set true to the vma's purge state so if user try to access
purged vma without calling mnovolatile, it will encounter SIGBUS.
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Hugh Dickins
Signed-off-by: Minchan Kim
---
include/linux/memory.h|2 +
include/linux/mvolatile.h | 20 +
include/linux/rmap.h |2 +
mm/memory.c | 10 ++-
mm/mvolatile.c| 185 -
mm/rmap.c |3 +-
mm/vmscan.c | 13
7 files changed, 230 insertions(+), 5 deletions(-)
diff --git a/include/linux/memory.h b/include/linux/memory.h
index ff9a9f8..0c50bec 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -150,5 +150,7 @@ struct memory_accessor {
* can sleep.
*/
extern struct mutex text_mutex;
+void print_bad_pte(struct vm_area_struct *vma, unsigned long addr,
+ pte_t pte, struct page *page);
#endif /* _LINUX_MEMORY_H_ */
diff --git a/include/linux/mvolatile.h b/include/linux/mvolatile.h
index cfb12b4..eb07761 100644
--- a/include/linux/mvolatile.h
+++ b/include/linux/mvolatile.h
@@ -2,8 +2,15 @@
#define __LINUX_MVOLATILE_H
#include
+#include
#ifdef CONFIG_VOLATILE_PAGE
+
+static inline bool is_volatile_vma(struct vm_area_struct *vma)
+{
+ return vma->vm_flags & VM_VOLATILE;
+}
+
static inline bool vma_purged(struct vm_area_struct *vma)
{
return vma->purged;
@@ -14,6 +21,8 @@ static inline void vma_purge_copy(struct vm_area_struct *dst,
{
dst->purged = src->purged;
}
+
+int discard_volatile_page(struct page *page, enum ttu_flags ttu_flags);
#else
static inline bool vma_purged(struct vm_area_struct *vma)
{
@@ -25,6 +34,17 @@ static inline void vma_purge_copy(struct vm_area_struct *dst,
{
}
+
+static inline int discard_volatile_page(struct page *page,
+ enum ttu_flags ttu_flags)
+{
+ return 0;
+}
+
+static inline bool is_volatile_vma(struct vm_area_struct *vma)
+{
+ return false;
+}
#endif
#endif
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index bfe1f47..5429804 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -223,6 +223,7 @@ int try_to_munlock(struct page *);
struct anon_vma *page_lock_anon_vma(struct page *page);
void page_unlock_anon_vma(struct anon_vma *anon_vma);
int page_mapped_in_vma(struct page *page, struct vm_area_struct *vma);
+unsigned long vma_address(struct page *page, struct vm_area_struct *vma);
/*
* Called by migrate.c to remove migration ptes, but might be used more later.
@@ -244,6 +245,7 @@ static inline int page_referenced(struct page *page, int
is_locked,
return 0;
}
+
#define try_to_unmap(page, refs) SWAP_FAIL
static inline int page_mkclean(struct page *page)
diff --git a/mm/memory.c b/mm/memory.c
index c475cc1..0646375 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include
#include
@@ -655,7 +656,7 @@ static inline void add_mm_rss_vec(struct mm_struct *mm, int
*rss)
*
* The calling function must still handle the error.
*/
-static void print_bad_pte(struct vm_area_struct *vma, unsigned long addr,
+void print_bad_pte(struct vm_area_struct *vma, unsigned long addr,
pte_t pte, struct page *page)
{
pgd_t *pgd = pgd_offset(vma->vm_mm, addr);
@@ -3459,6 +3460,8 @@ int handle_pte_fault(struct mm_struct *mm,
return do_linear_fault(mm, vma, address,
pte, pmd, flags, entry);
}
+ if (unlikely(is_volatile_vma(vma)))
+ return VM_FAULT_SIGBUS;
return do_anonymous_page(mm, vma, address,
pte, pmd, flags);
}
@@ -3528,9 +3531,12 @@ retry:
if (!pmd)
return VM_FAULT_OOM;
if (pmd_none(*pmd) && transparent_hugepage_enabled(vma)) {
- if (!vma->vm_ops)
+ if (!vma->vm_ops) {
+ if (unlikely(is_volatile_vma(vma)))
+ return VM_FAULT_SIGBUS;
return do_huge_pmd_anonymous_page(mm, vma, address,
pmd, flags);
+ }
} else {
pmd_t orig_pmd = *pmd;
int ret;
diff --git a/mm/mvolatile.c b/mm/mvolatile.c
index 8b812d2..6bc9f7e 100644
--- a/mm/mvolatile.c
+++ b/mm/mvolatile.c
@@ -10,8 +10,12 @@
#include
#include
#include
-#include
+#include
#include
+#include
+#include
+#include
+#include
#ifndef CONFIG_VOLATILE_PAGE
SYSCALL_DEFINE2(mnovolatile, unsigned long, start, size_t, len)
@@ -25,6 +29,185 @@ SYSCALL_DEFINE2(mvolatile, unsigned long, start, size
[RFC 6/8] add PGVOLATILE vmstat count
This patch add pgvolatile vmstat so admin can see how many of volatile
pages are discarded by VM until now.
Signed-off-by: Minchan Kim
---
include/linux/vm_event_item.h |3 +++
mm/mvolatile.c|1 +
mm/vmstat.c |3 +++
3 files changed, 7 insertions(+)
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 3d31145..721d096 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -25,6 +25,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
FOR_ALL_ZONES(PGALLOC),
PGFREE, PGACTIVATE, PGDEACTIVATE,
PGFAULT, PGMAJFAULT,
+#ifdef CONFIG_VOLATILE_PAGE
+ PGVOLATILE,
+#endif
FOR_ALL_ZONES(PGREFILL),
FOR_ALL_ZONES(PGSTEAL_KSWAPD),
FOR_ALL_ZONES(PGSTEAL_DIRECT),
diff --git a/mm/mvolatile.c b/mm/mvolatile.c
index 6bc9f7e..c66c3bc 100644
--- a/mm/mvolatile.c
+++ b/mm/mvolatile.c
@@ -201,6 +201,7 @@ int discard_volatile_page(struct page *page, enum ttu_flags
ttu_flags)
if (try_to_volatile_page(page, ttu_flags)) {
if (page_freeze_refs(page, 1)) {
unlock_page(page);
+ count_vm_event(PGVOLATILE);
return 1;
}
}
diff --git a/mm/vmstat.c b/mm/vmstat.c
index c737057..3d08e1a 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -753,6 +753,9 @@ const char * const vmstat_text[] = {
"pgfault",
"pgmajfault",
+#ifdef CONFIG_VOLATILE_PAGE
+ "pgvolatile",
+#endif
TEXTS_FOR_ZONES("pgrefill")
TEXTS_FOR_ZONES("pgsteal_kswapd")
TEXTS_FOR_ZONES("pgsteal_direct")
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 8/8] extend PGVOLATILE vmstat to kswapd
Now kswapd can discard volatile pages so let's cover it for vmstat.
Signed-off-by: Minchan Kim
---
include/linux/vm_event_item.h |3 ++-
mm/mvolatile.c|5 -
mm/vmstat.c |3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 721d096..4efa3bf 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -26,7 +26,8 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
PGFREE, PGACTIVATE, PGDEACTIVATE,
PGFAULT, PGMAJFAULT,
#ifdef CONFIG_VOLATILE_PAGE
- PGVOLATILE,
+ PGVOLATILE_DIRECT,
+ PGVOLATILE_KSWAPD,
#endif
FOR_ALL_ZONES(PGREFILL),
FOR_ALL_ZONES(PGSTEAL_KSWAPD),
diff --git a/mm/mvolatile.c b/mm/mvolatile.c
index 1c7bf5a..08a7eb3 100644
--- a/mm/mvolatile.c
+++ b/mm/mvolatile.c
@@ -246,7 +246,10 @@ int discard_volatile_page(struct page *page, enum
ttu_flags ttu_flags)
if (try_to_volatile_page(page, ttu_flags)) {
if (page_freeze_refs(page, 1)) {
unlock_page(page);
- count_vm_event(PGVOLATILE);
+ if (current_is_kswapd())
+ count_vm_event(PGVOLATILE_KSWAPD);
+ else
+ count_vm_event(PGVOLATILE_DIRECT);
return 1;
}
}
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 3d08e1a..416f550 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -754,7 +754,8 @@ const char * const vmstat_text[] = {
"pgmajfault",
#ifdef CONFIG_VOLATILE_PAGE
- "pgvolatile",
+ "pgvolatile_direct",
+ "pgvolatile_kswapd",
#endif
TEXTS_FOR_ZONES("pgrefill")
TEXTS_FOR_ZONES("pgsteal_kswapd")
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 7/8] add volatile page discard hook to kswapd
This patch adds volatile page discard hook to kswapd for
minimizing eviction of working set and enable discarding
volatile page although we don't turn on swap.
This patch is copied heavily from THP.
Cc: Hugh Dickins
Cc: Andrea Arcangeli
Cc: Rik van Riel
Cc: Mel Gorman
Signed-off-by: Minchan Kim
---
include/linux/mvolatile.h | 13 ++
include/linux/sched.h |1 +
kernel/fork.c |2 +
mm/internal.h |2 +
mm/mvolatile.c| 314 +
mm/vmscan.c | 44 ++-
6 files changed, 374 insertions(+), 2 deletions(-)
diff --git a/include/linux/mvolatile.h b/include/linux/mvolatile.h
index eb07761..9276022 100644
--- a/include/linux/mvolatile.h
+++ b/include/linux/mvolatile.h
@@ -23,6 +23,9 @@ static inline void vma_purge_copy(struct vm_area_struct *dst,
}
int discard_volatile_page(struct page *page, enum ttu_flags ttu_flags);
+unsigned int discard_volatile_pages(struct zone *zone, unsigned int nr_pages);
+void mvolatile_exit(struct mm_struct *mm);
+
#else
static inline bool vma_purged(struct vm_area_struct *vma)
{
@@ -45,6 +48,16 @@ static inline bool is_volatile_vma(struct vm_area_struct
*vma)
{
return false;
}
+
+static inline unsigned int discard_volatile_pages(struct zone *zone,
+ unsigned int nr_pages)
+{
+ return 0;
+}
+
+static inline void mvolatile_exit(struct mm_struct *mm)
+{
+}
#endif
#endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0dd42a0..7ae95df 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -408,6 +408,7 @@ extern int get_dumpable(struct mm_struct *mm);
#define MMF_HAS_UPROBES19 /* has uprobes */
#define MMF_RECALC_UPROBES 20 /* MMF_HAS_UPROBES can be wrong */
+#define MMF_VM_VOLATILE21 /* set when VM_VOLATILE is set
on vma */
#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK)
diff --git a/kernel/fork.c b/kernel/fork.c
index 8b20ab7..9d7d218 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -70,6 +70,7 @@
#include
#include
#include
+#include
#include
#include
@@ -612,6 +613,7 @@ void mmput(struct mm_struct *mm)
uprobe_clear_state(mm);
exit_aio(mm);
ksm_exit(mm);
+ mvolatile_exit(mm);
khugepaged_exit(mm); /* must run before exit_mmap */
exit_mmap(mm);
set_mm_exe_file(mm, NULL);
diff --git a/mm/internal.h b/mm/internal.h
index a4fa284..e595224 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -351,6 +351,8 @@ extern unsigned long vm_mmap_pgoff(struct file *, unsigned
long,
unsigned long, unsigned long);
extern void set_pageblock_order(void);
+unsigned long discard_volatile_page_list(struct zone *zone,
+ struct list_head *page_list);
unsigned long reclaim_clean_pages_from_list(struct zone *zone,
struct list_head *page_list);
/* The ALLOC_WMARK bits are used as an index to zone->watermark */
diff --git a/mm/mvolatile.c b/mm/mvolatile.c
index c66c3bc..1c7bf5a 100644
--- a/mm/mvolatile.c
+++ b/mm/mvolatile.c
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include "internal.h"
#ifndef CONFIG_VOLATILE_PAGE
SYSCALL_DEFINE2(mnovolatile, unsigned long, start, size_t, len)
@@ -29,6 +31,49 @@ SYSCALL_DEFINE2(mvolatile, unsigned long, start, size_t, len)
}
#else
+static DEFINE_SPINLOCK(mvolatile_mm_lock);
+
+#define MM_SLOTS_HASH_SHIFT 10
+#define MM_SLOTS_HASH_HEADS (1 << MM_SLOTS_HASH_SHIFT)
+
+struct mvolatile_scan {
+ struct list_head mm_head;
+ struct mm_slot *mm_slot;
+ unsigned long address;
+};
+
+static struct mvolatile_scan mvolatile_scan = {
+ .mm_head = LIST_HEAD_INIT(mvolatile_scan.mm_head),
+};
+
+static struct hlist_head mm_slots_hash[MM_SLOTS_HASH_HEADS];
+
+struct mm_slot {
+ struct hlist_node hash;
+ struct list_head mm_node;
+ struct mm_struct *mm;
+};
+
+static struct kmem_cache *mm_slot_cache __read_mostly;
+
+static int __init mvolatile_slab_init(void)
+{
+ mm_slot_cache = kmem_cache_create("mvolatile_mm_slot",
+ sizeof(struct mm_slot),
+ __alignof(struct mm_slot), 0, NULL);
+ if (!mm_slot_cache)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int __init mvolatile_init(void)
+{
+ mvolatile_slab_init();
+ return 0;
+}
+module_init(mvolatile_init)
+
/*
* Check that @page is mapped at @address into @mm
* The difference with __page_check_address is this function checks
@@ -209,6 +254,274 @@ int discard_volatile_page(struct page *page, enum
ttu_flags ttu_flags)
return 0;
}
+
+static inline struct mm_slot *alloc_mm_slot(void)
+{
+ if (!mm_slot_cache)
+ return NULL;
+ retur
[RFC v5 0/8] Support volatile for anonymous range
This is still RFC because we need more input from user-space people, more stress test, design discussion about interface/reclaim policy of volatile pages and I want to expand this concept to tmpfs volatile range if it is possbile without big performance drop of anonymous volatile range. (Let's define our term. anon volatile VS tmpfs volatile? John?) I hope more inputs from user-space allocator people and test patch with their allocator because it might need design change of arena management for getting real vaule. TODO * Improve volatile range scanning speed * Aware of NUMA policy with vma's mempolicy * Add direct reclaim hook for discarding volatile pages first * Support tmpfs-volatile Changelog from v5 - There are many changes. * Support CONFIG_VOLATILE_PAGE * Working with THP/KSM * Remove vma hacking logic in m[no]volatile system call * Discard page without swap cache * Kswapd discard volatile page so we can discard volatile pages although we don't have swap. Changelog from v4 * Add new system call mvolatile/mnovolatile * Add sigbus when user try to access volatile range * Rebased on v3.7 * Applied bug fix from John Stultz, Thanks! Changelog from v3 * Removing madvise(addr, length, MADV_NOVOLATILE). * add vmstat about the number of discarded volatile pages * discard volatile pages without promotion in reclaim path This is based on v3.7 - What's the mvolatile(addr, length)? It's a hint that user deliver to kernel so kernel can *discard* pages in a range anytime. - What happens if user access page(ie, virtual address) discarded by kernel? The user can encounter SIGBUS. - What should user do for avoding SIGBUS? He should call mnovolatie(addr, length) before accessing the range which was called by mvolatile. - What happens if user access page(ie, virtual address) doesn't discarded by kernel? The user can see old data without page fault. - What's different with madvise(DONTNEED)? System call semantic DONTNEED makes sure user always can see zero-fill pages after he calls madvise while mvolatile can see old data or encounter SIGBUS. Internal implementation The madvise(DONTNEED) should zap all mapped pages in range so overhead is increased linearly with the number of mapped pages. Even, if user access zapped pages as write mode, page fault + page allocation + memset should be happened. The mvolatile just marks the flag in a range(ie, VMA) instead of zapping all of pte in the vma so it doesn't touch ptes any more. - What's the benefit compared to DONTNEED? 1. The system call overhead is smaller because mvolatile just marks the flag to VMA instead of zapping all the page in a range so overhead should be very small. 2. It has a chance to eliminate overheads (ex, zapping pte + page fault + page allocation + memset(PAGE_SIZE)) if memory pressure isn't severe. 3. It has a potential to zap all ptes and free the pages if memory pressure is severe so reclaim overhead could be disappear - TODO - Isn't there any drawback? Madvise(DONTNEED) doesn't need exclusive mmap_sem so concurrent page fault of other threads could be allowed. But m[no]volatile needs exclusive mmap_sem so other thread would be blocked if they try to access not-yet-mapped pages. That's why I design m[no]volatile overhead should be small as far as possible. It could suffer from max rss usage increasement because madvise(DONTNEED) deallocates pages instantly when the system call is issued while mvoatile delays it until memory pressure happens so if memory pressure is severe by max rss incresement, system would suffer. First of all, allocator needs some balance logic for that or kernel might handle it by zapping pages although user calls mvolatile if memory pressure is severe. The problem is how we know memory pressure is severe. One of solution is to see kswapd is active or not. Another solution is Anton's mempressure so allocator can handle it. - What's for targetting? Firstly, user-space allocator like ptmalloc, tcmalloc or heap management of virtual machine like Dalvik. Also, it comes in handy for embedded which doesn't have swap device so they can't reclaim anonymous pages. By discarding instead of swapout, it could be used in the non-swap system. - Stupid performance test I attach test program/script which are utter crap and I don't expect current smart allocator never have done it so we need more practical data with real allocator. KVM - 8 core, 2G VOLATILE test 13.16user 7.58system 0:06.04elapsed 343%CPU (0avgtext+0avgdata 2624096maxresident)k 0inputs+0outputs (0major+164050minor)pagefaults 0swaps DONTNEED test 23.30user 228.92system 0:33.10elapsed 762%CPU (0avgtext+0avgdata 213088maxresident)k 0inputs+0outputs (0major+16384210minor)pagefaults 0swaps x86-64 - 12 core, 2G VOLATILE test 33.38user 0.44system 0:02.87elapsed 1178%CPU (0avgtext+0avgdata 3935008maxresident)k 0inputs+0
[RFC 3/8] bail out when the page is in VOLATILE vma
If we found a page is in VOLATILE vma, hurry up discarding
instead of access bit check because it's very unlikey working set.
Next patch will use it.
Cc: Rik van Riel
Cc: Mel Gorman
Signed-off-by: Minchan Kim
---
mm/rmap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 402d9da..fea01cd 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -695,10 +695,12 @@ int page_referenced_one(struct page *page, struct
vm_area_struct *vma,
if (!pte)
goto out;
- if (vma->vm_flags & VM_LOCKED) {
+ if ((vma->vm_flags & VM_LOCKED) ||
+ (vma->vm_flags & VM_VOLATILE)) {
pte_unmap_unlock(pte, ptl);
*mapcount = 0; /* break early from loop */
- *vm_flags |= VM_LOCKED;
+ *vm_flags |= (vma->vm_flags & VM_LOCKED ?
+ VM_LOCKED : VM_VOLATILE);
goto out;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 4/8] add page_locked parameter in free_swap_and_cache
Add page_locked parameter for avoiding trylock_page.
Next patch will use it.
Cc: Hugh Dickins
Cc: Mel Gorman
Cc: Rik van Riel
Signed-off-by: Minchan Kim
---
include/linux/swap.h |6 +++---
mm/fremap.c |2 +-
mm/memory.c |2 +-
mm/shmem.c |2 +-
mm/swapfile.c|7 ---
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 68df9c1..5cf2191 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -357,7 +357,7 @@ extern int swap_duplicate(swp_entry_t);
extern int swapcache_prepare(swp_entry_t);
extern void swap_free(swp_entry_t);
extern void swapcache_free(swp_entry_t, struct page *page);
-extern int free_swap_and_cache(swp_entry_t);
+extern int free_swap_and_cache(swp_entry_t, bool);
extern int swap_type_of(dev_t, sector_t, struct block_device **);
extern unsigned int count_swap_pages(int, int);
extern sector_t map_swap_page(struct page *, struct block_device **);
@@ -397,8 +397,8 @@ static inline void show_swap_cache_info(void)
{
}
-#define free_swap_and_cache(swp) is_migration_entry(swp)
-#define swapcache_prepare(swp) is_migration_entry(swp)
+#define free_swap_and_cache(swp, page_locked) is_migration_entry(swp)
+#define swapcache_prepare(swp) is_migration_entry(swp)
static inline int add_swap_count_continuation(swp_entry_t swp, gfp_t gfp_mask)
{
diff --git a/mm/fremap.c b/mm/fremap.c
index a0aaf0e..a300508 100644
--- a/mm/fremap.c
+++ b/mm/fremap.c
@@ -44,7 +44,7 @@ static void zap_pte(struct mm_struct *mm, struct
vm_area_struct *vma,
}
} else {
if (!pte_file(pte))
- free_swap_and_cache(pte_to_swp_entry(pte));
+ free_swap_and_cache(pte_to_swp_entry(pte), false);
pte_clear_not_present_full(mm, addr, ptep, 0);
}
}
diff --git a/mm/memory.c b/mm/memory.c
index 221fc9f..c475cc1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1198,7 +1198,7 @@ again:
else
rss[MM_FILEPAGES]--;
}
- if (unlikely(!free_swap_and_cache(entry)))
+ if (unlikely(!free_swap_and_cache(entry, false)))
print_bad_pte(vma, addr, ptent, NULL);
}
pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
diff --git a/mm/shmem.c b/mm/shmem.c
index 50c5b8f..33ec719 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -391,7 +391,7 @@ static int shmem_free_swap(struct address_space *mapping,
error = shmem_radix_tree_replace(mapping, index, radswap, NULL);
spin_unlock_irq(&mapping->tree_lock);
if (!error)
- free_swap_and_cache(radix_to_swp_entry(radswap));
+ free_swap_and_cache(radix_to_swp_entry(radswap), false);
return error;
}
diff --git a/mm/swapfile.c b/mm/swapfile.c
index f91a255..43437ff 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -688,7 +688,7 @@ int try_to_free_swap(struct page *page)
* Free the swap entry like above, but also try to
* free the page cache entry if it is the last user.
*/
-int free_swap_and_cache(swp_entry_t entry)
+int free_swap_and_cache(swp_entry_t entry, bool page_locked)
{
struct swap_info_struct *p;
struct page *page = NULL;
@@ -700,7 +700,7 @@ int free_swap_and_cache(swp_entry_t entry)
if (p) {
if (swap_entry_free(p, entry, 1) == SWAP_HAS_CACHE) {
page = find_get_page(&swapper_space, entry.val);
- if (page && !trylock_page(page)) {
+ if (page && !page_locked && !trylock_page(page)) {
page_cache_release(page);
page = NULL;
}
@@ -717,7 +717,8 @@ int free_swap_and_cache(swp_entry_t entry)
delete_from_swap_cache(page);
SetPageDirty(page);
}
- unlock_page(page);
+ if (!page_locked)
+ unlock_page(page);
page_cache_release(page);
}
return p != NULL;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jan 3
Hi all, Changes since 20130102: The net-next tree gained a build failure for which I applied a patch. The kvm tree gained a conflict against the s390 tree. The pinctrl tree gained a conflict against the driver-core.current tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 213 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (5439ca6 Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging fixes/master (3b095f2 disable the SB105X driver) Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by list_head-style lists.) Merging arm-current/fixes (5ced33b ARM: 7611/1: VIC: fix bug in VIC irqdomain code) Merging m68k-current/for-linus (e7e29b4 m68k: Wire up finit_module) Merging powerpc-merge/merge (e716e01 powerpc/eeh: Do not invalidate PE properly) Merging sparc/master (4e4d78f sparc: Hook up finit_module syscall.) Merging net/master (612a7c4 forcedeth: Fix WARNINGS that result when DMA mapping is not checked) Merging sound-current/for-linus (a49f0d1 Linux 3.8-rc1) Merging pci-current/for-linus (812089e PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz) Merging wireless/master (619c5a9 brcmfmac: fix parsing rsn ie for ap mode.) Merging driver-core.current/driver-core-linus (76da5cf Drivers: i2c: fix i2c-au1550.c build error) CONFLICT (content): Merge conflict in drivers/i2c/muxes/i2c-mux-gpio.c CONFLICT (content): Merge conflict in drivers/i2c/busses/scx200_acb.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-xiic.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-viapro.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-sis96x.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-pxa-pci.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-powermac.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-piix4.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-pasemi.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-omap.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-nforce2.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-mv64xxx.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-mpc.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-intel-mid.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-ibm_iic.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-i801.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-hydra.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-eg20t.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-designware-pcidrv.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-au1550.c CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-ali1563.c Merging tty.current/tty-linus (a49f0d1 Linux 3.8-rc1) Merging usb.current/usb-linus (a49f0d1 Linux 3.8-rc1) Merging staging.current/staging-linus (a49f0d1 Linux 3.8-rc1) Merging char-misc.current/char-misc-linus (a49f0d1 Linux 3.8-rc1) Merging input-current/for-linus
Linux 3.8-rc2
It's a new year, people are getting back to work, and trying desperately to forget the over-eating that has been going on for the last two weeks. And hey, to celebrate, here's -rc2! The patch is fairly small, and largely dominated by the GPU updates and the trivial removal of __devinit/exit in the i2c layer. But there's some filesystem work (ext4, ecryptfs, ceph) and some VM fixes in there to. And some late ARM OMAP cleanups. The shortlog is appended, my "mergelog" looks like this: Wolfram Sang: i2c __dev* attribute removal David Miller: networking fixes Eric Biederman: namespace fixes Guenter Roeck: hwmon fixes Olof Johansson: ARM SoC fixes late ARM cleanups for omap Dave Airlie: DRM update Ted Ts'o: ext4 bug fixes Sage Weil: Ceph fixes Tyler Hicks: ecryptfs fixes Bjorn Helgaas: PCI updates Wim Van Sebroeck: watchdog fixes Bryan Wu. LED fix Go out and test it, Linus --- Aaro Koskinen (2): watchdog: omap_wdt: eliminate unused variable and a compiler warning watchdog: twl4030_wdt: add DT support Akinobu Mita (1): batman-adv: fix random jitter calculation Alex Deucher (1): drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list Alex Elder (3): libceph: move linger requests sooner in kick_requests() libceph: always reset osds when kicking libceph: WARN, don't BUG on unexpected connection states Andy Lutomirski (2): ext4: fix an incorrect comment about i_mutex PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz AnilKumar Chimata (1): ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support Axel Lin (2): watchdog: da9055: Fix invalid free of devm_ allocated data watchdog: da9055: Don't update wdt_dev->timeout in da9055_wdt_set_timeout error path Ben Skeggs (8): drm/nouveau: initial support for GK106 drm/nouveau/bios: update gpio parsing apis to match current design drm/nouveau/bios: implement opcode 0xa9 drm/nouveau/bios: parse/display extra version component drm/nouveau/mxm: silence output if no bios data drm/nouveau/bios: cache ramcfg strap on later chipsets drm/nvc0/graph: fix fuc, and enable acceleration on GF119 drm/nve0/graph: fix fuc, and enable acceleration on all known chipsets Bill Pemberton (1): i2c: remove __dev* attributes from subsystem Bjorn Helgaas (2): PCI: Remove spurious error for sriov_numvfs store and simplify flow PCI: Add PCIe Link Capability link speed and width names Chris Verges (1): hwmon: (lm73} Detect and report i2c bus errors Chris Wilson (6): drm/i915: Fixup cursor latency used for IVB lp3 watermarks drm/i915: Double the cursor self-refresh latency on Valleyview drm/i915: Clear self-refresh watermarks when disabled drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM computations drm: Export routines for inserting preallocated nodes into the mm manager drm/i915: Preallocate the drm_mm_node prior to manipulating the GTT drm_mm manager Christoffer Dall (1): mm: Fix PageHead when !CONFIG_PAGEFLAGS_EXTENDED Cong Ding (1): fs/ecryptfs/crypto.c: make ecryptfs_encode_for_filename() static Cong Wang (1): arp: fix a regression in arp_solicit() Dan Carpenter (1): solos-pci: double lock in geos_gpio_store() Daniel Vetter (6): drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled drm/i915: Implement WaSetupGtModeTdRowDispatch drm/i915: Implement workaround for broken CS tlb on i830/845 drm/i915: don't disable disconnected outputs drm/i915: optionally disable shrinker lock stealing drm/i915: disable shrinker lock stealing for create_mmap_offset Dave Airlie (2): drm/i915: fix flags in dma buf exporting Revert "drm: tegra: protect DC register access with mutex" David Howells (2): UAPI: Remove empty Kbuild files UAPI: Strip _UAPI prefix on header install no matter the whitespace Eric Dumazet (5): ip_gre: fix possible use after free net: devnet_rename_seq should be a seqcount tuntap: dont use a private kmem_cache ipv4: arp: fix a lockdep splat in arp_solicit() tcp: should drop incoming frames without ACK flag set Eric Sandeen (2): ext4: remove unaligned AIO warning printk ext4: include journal blocks in df overhead calcs Eric W. Biederman (4): pidns: Outlaw thread creation after unshare(CLONE_NEWPID) pidns: Stop pid allocation when init dies proc: Allow proc_free_inum to be called from any context f2fs: Don't assign e_id in f2fs_acl_from_disk Eric Wong (1): epoll: prevent missed events on EPOLL_CTL_MOD Forrest Liu (1): ext4: fix extent tree corruption caused by hole punch Gao feng (1): bridge: call br_netpoll_disable in br_add_if Greg KH (2): Drivers: network: more
Re: [PATCH 1/3] cpufreq: Manage only online cpus
On 3 January 2013 06:43, Rafael J. Wysocki wrote: >> BTW, i consider them as fixes and so would make sense to get them in next rc. >> What do you think? > > Yes, if somebody tells me "yes, this fixes a problem for me". Otherwise, > I don't quite see the reason. I don't know how much people test HOTPLUG, but there are clear bugs related to hotplug of cpus on a multiple cpu system :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/8] Support for Tegra 2D hardware
On 01/02/2013 05:42 PM, Terje Bergström wrote:
> On 28.12.2012 11:14, Mark Zhang wrote:
>> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
>> index a936902..c3ded60 100644
>> --- a/drivers/gpu/drm/tegra/gr2d.c
>> +++ b/drivers/gpu/drm/tegra/gr2d.c
>> @@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
>> *context,
>> if (err)
>> goto fail;
>>
>> + /* We define CMA as an temporary solution in host1x driver.
>> + That's also why we have a CMA kernel config in it.
>> + But seems here, in tegradrm, we hardcode the CMA here.
>> + So what do you do when host1x change to IOMMU?
>> + Do we also need to define a CMA config in tegradrm
>> driver,
>> + then after host1x changes to IOMMU, we add another IOMMU
>> + config in tegradrm? Or we should invent another more
>> + generic wrapper layer here? */
>> cmdbuf.mem = handle_cma_to_host1x(drm, file_priv,
>> cmdbuf.mem);
>
> Lucas is working on host1x allocator, so let's defer this comment until
> we have Lucas' code.
>
OK.
>> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
>> index cc8ca2f..0867b72 100644
>> --- a/drivers/gpu/host1x/job.c
>> +++ b/drivers/gpu/host1x/job.c
>> @@ -82,6 +82,26 @@ struct host1x_job *host1x_job_alloc(struct
>> host1x_channel *ch,
>> mem += num_unpins * sizeof(dma_addr_t);
>> job->pin_ids = num_unpins ? mem : NULL;
>>
>> + /* I think this is a somewhat ugly design.
>> + Actually "addr_phys" is consisted by "reloc_addr_phys" and
>> + "gather_addr_phys".
>> + Why don't we just declare "reloc_addr_phys" and
>> "gather_addr_phys"?
>> + In current design, let's say if one nvhost newbie changes the
>> order
>> + of these 2 blocks of code in function "pin_job_mem":
>> +
>> + for (i = 0; i < job->num_relocs; i++) {
>> + struct host1x_reloc *reloc = &job->relocarray[i];
>> + job->pin_ids[count] = reloc->target;
>> + count++;
>> + }
>> +
>> + for (i = 0; i < job->num_gathers; i++) {
>> + struct host1x_job_gather *g = &job->gathers[i];
>> + job->pin_ids[count] = g->mem_id;
>> + count++;
>> + }
>> +
>> + Then likely something weird occurs... */
>
> We do this because this way we can implement batch pinning of memory
> handles. This way we can decrease memory handle management a lot as we
> need to do locking only once per submit.
>
Sorry I didn't get it. Yes, in current design, you can pin all mem
handles in one time but I haven't found anything related with "locking
only once per submit".
My idea is:
- remove "job->addr_phys"
- assign "job->reloc_addr_phys" & "job->gather_addr_phys" separately
- In "pin_job_mem", just call "host1x_memmgr_pin_array_ids" twice to
fill the "reloc_addr_phy" & "gather_addr_phys".
Anything I misunderstood?
> Decreasing memory management overhead is really important, because in
> complex graphics cases, there are might be a hundreds of buffer
> references per submit, and several submits per frame. Any extra overhead
> relates directly to reduced performance.
>
>> job->reloc_addr_phys = job->addr_phys;
>> job->gather_addr_phys = &job->addr_phys[num_relocs];
>>
>> @@ -252,6 +272,10 @@ static int do_relocs(struct host1x_job *job,
>> }
>> }
>>
>> + /* I have question here. Does this mean the address info
>> + which need to be relocated(according to the libdrm codes,
>> + seems this address is "0xDEADBEEF") always staying at the
>> + beginning of a page? */
>> __raw_writel(
>> (job->reloc_addr_phys[i] +
>> reloc->target_offset) >> reloc->shift,
>
> No - the slot can be anywhere. That's why we have cmdbuf_offset in the
> reloc struct.
>
Yes. Sorry I must misread the code before.
>> @@ -565,6 +589,7 @@ int host1x_job_pin(struct host1x_job *job, struct
>> platform_device *pdev)
>> }
>> }
>>
>> + /* if (host1x_firewall && !err) { */
>> if (host1x_firewall) {
>> err = copy_gathers(job, pdev);
>> if (err) {
>
> Will add.
>
>> @@ -573,6 +598,9 @@ int host1x_job_pin(struct host1x_job *job, struct
>> platform_device *pdev)
>> }
>> }
>>
>> +/* Rename this label to "out" or something else.
>> + Because if everything goes right, the codes under this label also
>> + get executed. */
>> fail:
>> wmb();
>
> Will do.
>
>>
>> diff --git a/drivers/gpu/host1x/memmgr.c b/drivers/gpu/host1x/memmgr.c
>> index f3954f7..bb5763d 100644
>> --- a/drivers/gpu/host1x/memmgr.c
>> +++ b/drivers/gpu/host1x/memmgr.
Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell
Date: Thu, 3 Jan 2013 14:23:53 +1100
> Caused by commit 13159183ec7a ("qlcnic: 83xx base driver") from the
> net-next tree. Why is this commit adding a function that already exists
> globally?
And this is after I pushed back on this patch series 5 times or so.
You qlogic guys, can you see why I give you such a hard time with
your patch submissions? Even after I ask you to correct all of the
most obvious problems, there is still garbage like this that shows
up in your changes.
What in the world do I have to do, other than push back on your
submissions even harder, to keep crap like this from happening
in the future?
Tell me.
You, as a group, are the absolute worst networking driver submitters.
This is a real problem because you submit large bodies of code that 1)
nobody wants to review and 2) has a very small user base. So you
impart an extremely large burdon upon me, in particular, because I'm
the only person that actually reviews your code at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] irqchip: vt8500: Move irq code to drivers/irqchip
Move mach-vt8500/irq.c to drivers/irqchip/irq-vt8500.c and make
necessary Makefile changes. No code changes required.
Signed-off-by: Tony Prisk
---
CC: Thomas Gleixner
arch/arm/mach-vt8500/Makefile |2 +-
arch/arm/mach-vt8500/common.h |7 +-
arch/arm/mach-vt8500/irq.c| 253 -
drivers/irqchip/Makefile |1 +
drivers/irqchip/irq-vt8500.c | 253 +
5 files changed, 258 insertions(+), 258 deletions(-)
delete mode 100644 arch/arm/mach-vt8500/irq.c
create mode 100644 drivers/irqchip/irq-vt8500.c
diff --git a/arch/arm/mach-vt8500/Makefile b/arch/arm/mach-vt8500/Makefile
index 92ceb24..4c8a846 100644
--- a/arch/arm/mach-vt8500/Makefile
+++ b/arch/arm/mach-vt8500/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_VT8500) += irq.o vt8500.o
+obj-$(CONFIG_ARCH_VT8500) += vt8500.o
diff --git a/arch/arm/mach-vt8500/common.h b/arch/arm/mach-vt8500/common.h
index 5d37a4f..b198a81 100644
--- a/arch/arm/mach-vt8500/common.h
+++ b/arch/arm/mach-vt8500/common.h
@@ -18,13 +18,12 @@
#include
-int __init vt8500_irq_init(struct device_node *node,
- struct device_node *parent);
-
/* defined in drivers/clk/clk-vt8500.c */
void __init vtwm_clk_init(void __iomem *pmc_base);
-/* defined in irq.c */
+/* defined in drivers/irqchip/irq.c */
+int __init vt8500_irq_init(struct device_node *node,
+ struct device_node *parent);
asmlinkage void vt8500_handle_irq(struct pt_regs *regs);
/* defined in drivers/clocksource/vt8500_timer.c */
diff --git a/arch/arm/mach-vt8500/irq.c b/arch/arm/mach-vt8500/irq.c
deleted file mode 100644
index b9cf5ce..000
--- a/arch/arm/mach-vt8500/irq.c
+++ /dev/null
@@ -1,253 +0,0 @@
-/*
- * arch/arm/mach-vt8500/irq.c
- *
- * Copyright (C) 2012 Tony Prisk
- * Copyright (C) 2010 Alexey Charkov
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-/*
- * This file is copied and modified from the original irq.c provided by
- * Alexey Charkov. Minor changes have been made for Device Tree Support.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#include
-#include
-
-#define VT8500_ICPC_IRQ0x20
-#define VT8500_ICPC_FIQ0x24
-#define VT8500_ICDC0x40/* Destination Control 64*u32 */
-#define VT8500_ICIS0x80/* Interrupt status, 16*u32 */
-
-/* ICPC */
-#define ICPC_MASK 0x3F
-#define ICPC_ROTATEBIT(6)
-
-/* IC_DCTR */
-#define ICDC_IRQ 0x00
-#define ICDC_FIQ 0x01
-#define ICDC_DSS0 0x02
-#define ICDC_DSS1 0x03
-#define ICDC_DSS2 0x04
-#define ICDC_DSS3 0x05
-#define ICDC_DSS4 0x06
-#define ICDC_DSS5 0x07
-
-#define VT8500_INT_DISABLE 0
-#define VT8500_INT_ENABLE BIT(3)
-
-#define VT8500_TRIGGER_HIGH0
-#define VT8500_TRIGGER_RISING BIT(5)
-#define VT8500_TRIGGER_FALLING BIT(6)
-#define VT8500_EDGE( VT8500_TRIGGER_RISING \
- | VT8500_TRIGGER_FALLING)
-
-/* vt8500 has 1 intc, wm8505 and wm8650 have 2 */
-#define VT8500_INTC_MAX2
-
-struct vt8500_irq_data {
- void __iomem*base; /* IO Memory base address */
- struct irq_domain *domain;/* Domain for this controller */
-};
-
-/* Global variable for accessing io-mem addresses */
-static struct vt8500_irq_data intc[VT8500_INTC_MAX];
-static u32 active_cnt = 0;
-
-static void vt8500_irq_mask(struct irq_data *d)
-{
- struct vt8500_irq_data *priv = d->domain->host_data;
- void __iomem *base = priv->base;
- void __iomem *stat_reg = base + VT8500_ICIS + (d->hwirq < 32 ? 0 : 4);
- u8 edge, dctr;
- u32 status;
-
- edge = readb(base + VT8500_ICDC + d->hwirq) & VT8500_EDGE;
- if (edge) {
- status = readl(stat_reg);
-
- status |= (1 << (d->hwirq & 0x1f));
- writel(status, stat_reg);
- } else {
- dctr = readb(base + VT8500_ICDC + d->hwirq);
- dctr &= ~VT8500_INT_ENABLE;
- writeb(dctr, base + VT8500_ICDC + d->hwirq);
- }
-}
-
[PATCH 0/2] Move some mach-vt8500 functions to new directories
These two patches move the irq and clocksource code out of mach-vt8500 and into drivers/irqchip and drivers/clocksource respectively. Because they affect the same files in mach-vt8500 I thought it may be easier if it goes through arm-soc, but I note Thomas is the maintainer for both irqchip and clocksource so maybe he wants to take both. CC: John Stultz CC: Thomas Gleixner Tony Prisk (2): timer: vt8500: Move system timer to clocksource irqchip: vt8500: Move irq code to drivers/irqchip arch/arm/mach-vt8500/Kconfig |1 + arch/arm/mach-vt8500/Makefile |2 +- arch/arm/mach-vt8500/common.h | 12 +- arch/arm/mach-vt8500/irq.c | 253 arch/arm/mach-vt8500/timer.c | 184 -- arch/arm/mach-vt8500/vt8500.c |4 - drivers/clocksource/Kconfig|3 + drivers/clocksource/Makefile |1 + drivers/clocksource/vt8500_timer.c | 187 ++ drivers/irqchip/Makefile |1 + drivers/irqchip/irq-vt8500.c | 253 11 files changed, 454 insertions(+), 447 deletions(-) delete mode 100644 arch/arm/mach-vt8500/irq.c delete mode 100644 arch/arm/mach-vt8500/timer.c create mode 100644 drivers/clocksource/vt8500_timer.c create mode 100644 drivers/irqchip/irq-vt8500.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] timer: vt8500: Move system timer to clocksource
Move mach-vt8500/timer.c to drivers/clocksource/vt8500_timer.c
and make necessary changes to Kconfig and Makefile.
vt8500_timer is moved from vt8500.c to clocksource/vt8500_timer.c
and added to common.h for reference from the board descriptor.
Signed-off-by: Tony Prisk
---
CC: John Stultz
CC: Thomas Gleixner
arch/arm/mach-vt8500/Kconfig |1 +
arch/arm/mach-vt8500/Makefile |2 +-
arch/arm/mach-vt8500/common.h |5 +-
arch/arm/mach-vt8500/timer.c | 184 ---
arch/arm/mach-vt8500/vt8500.c |4 -
drivers/clocksource/Kconfig|3 +
drivers/clocksource/Makefile |1 +
drivers/clocksource/vt8500_timer.c | 187
8 files changed, 197 insertions(+), 190 deletions(-)
delete mode 100644 arch/arm/mach-vt8500/timer.c
create mode 100644 drivers/clocksource/vt8500_timer.c
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index 2ed0b7d..570a801 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -8,5 +8,6 @@ config ARCH_VT8500
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
select HAVE_CLK
+ select VT8500_TIMER
help
Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
diff --git a/arch/arm/mach-vt8500/Makefile b/arch/arm/mach-vt8500/Makefile
index e035251..92ceb24 100644
--- a/arch/arm/mach-vt8500/Makefile
+++ b/arch/arm/mach-vt8500/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_VT8500) += irq.o timer.o vt8500.o
+obj-$(CONFIG_ARCH_VT8500) += irq.o vt8500.o
diff --git a/arch/arm/mach-vt8500/common.h b/arch/arm/mach-vt8500/common.h
index 6f2b843..5d37a4f 100644
--- a/arch/arm/mach-vt8500/common.h
+++ b/arch/arm/mach-vt8500/common.h
@@ -18,7 +18,6 @@
#include
-void __init vt8500_timer_init(void);
int __init vt8500_irq_init(struct device_node *node,
struct device_node *parent);
@@ -28,4 +27,8 @@ void __init vtwm_clk_init(void __iomem *pmc_base);
/* defined in irq.c */
asmlinkage void vt8500_handle_irq(struct pt_regs *regs);
+/* defined in drivers/clocksource/vt8500_timer.c */
+extern struct sys_timer vt8500_timer;
+void __init vt8500_timer_init(void);
+
#endif
diff --git a/arch/arm/mach-vt8500/timer.c b/arch/arm/mach-vt8500/timer.c
deleted file mode 100644
index 3dd21a4..000
--- a/arch/arm/mach-vt8500/timer.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * arch/arm/mach-vt8500/timer.c
- *
- * Copyright (C) 2012 Tony Prisk
- * Copyright (C) 2010 Alexey Charkov
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-/*
- * This file is copied and modified from the original timer.c provided by
- * Alexey Charkov. Minor changes have been made for Device Tree Support.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#define VT8500_TIMER_OFFSET0x0100
-#define VT8500_TIMER_HZ300
-#define TIMER_MATCH_VAL0x
-#define TIMER_COUNT_VAL0x0010
-#define TIMER_STATUS_VAL 0x0014
-#define TIMER_IER_VAL 0x001c /* interrupt enable */
-#define TIMER_CTRL_VAL 0x0020
-#define TIMER_AS_VAL 0x0024 /* access status */
-#define TIMER_COUNT_R_ACTIVE (1 << 5)/* not ready for read */
-#define TIMER_COUNT_W_ACTIVE (1 << 4)/* not ready for write */
-#define TIMER_MATCH_W_ACTIVE (1 << 0)/* not ready for write */
-
-#define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
-
-static void __iomem *regbase;
-
-static cycle_t vt8500_timer_read(struct clocksource *cs)
-{
- int loops = msecs_to_loops(10);
- writel(3, regbase + TIMER_CTRL_VAL);
- while ((readl((regbase + TIMER_AS_VAL)) & TIMER_COUNT_R_ACTIVE)
- && --loops)
- cpu_relax();
- return readl(regbase + TIMER_COUNT_VAL);
-}
-
-static struct clocksource clocksource = {
- .name = "vt8500_timer",
- .rating = 200,
- .read = vt8500_timer_read,
- .mask = CLOCKSOURCE_MASK(32),
- .flags = CLOCK_SOURCE_IS_CONTINUOUS,
-};
-
-static int vt8500_timer_set_next_event(unsigned long cycles,
-
linux-next: build failure after merge of the final tree (net-next tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/net/built-in.o: In function `pci_get_domain_bus_and_slot':
(.opd+0x449e8): multiple definition of `pci_get_domain_bus_and_slot'
drivers/pci/built-in.o:(.opd+0x1c98): first defined here
Caused by commit 13159183ec7a ("qlcnic: 83xx base driver") from the
net-next tree. Why is this commit adding a function that already exists
globally?
I added this patch for today:
From: Stephen Rothwell
Date: Thu, 3 Jan 2013 14:19:16 +1100
Subject: [PATCH] qlcnic: do not duplicate infrastructure functions
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index e1a3625..3bdb1beae 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -2,12 +2,6 @@
* QLogic qlcnic NIC Driver
* Copyright (c) 2009-2010 QLogic Corporation
*
- * PCI searching functions pci_get_domain_bus_and_slot & pci_channel_offline
- * Copyright (C) 1993 -- 1997 Drew Eckhardt, Frederic Potter,
- * David Mosberger-Tang
- * Copyright (C) 1997 -- 2000 Martin Mares
- * Copyright (C) 2003 -- 2004 Greg Kroah-Hartman .
- *
* See LICENSE.qlcnic for copyright and licensing details.
*/
@@ -25,6 +19,7 @@
#include
#include
#include
+#include
MODULE_DESCRIPTION("QLogic 1/10 GbE Converged/Intelligent Ethernet Driver");
MODULE_LICENSE("GPL");
@@ -2907,19 +2902,6 @@ reschedule:
qlcnic_schedule_work(adapter, qlcnic_fw_poll_work, FW_POLL_DELAY);
}
-struct pci_dev *pci_get_domain_bus_and_slot(int domain, unsigned int bus,
- unsigned int devfn)
-{
- struct pci_dev *dev = NULL;
-
- while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
- if (pci_domain_nr(dev->bus) == domain &&
- (dev->bus->number == bus && dev->devfn == devfn))
- return dev;
- }
- return NULL;
-}
-
static int qlcnic_is_first_func(struct pci_dev *pdev)
{
struct pci_dev *oth_pdev;
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpsrL0XEnw8S.pgp
Description: PGP signature
Re: INFO: rcu_bh detected stall on CPU 3 (t=0 jiffies)
On Wed, Jan 02, 2013 at 07:49:23PM -0500, Steven Rostedt wrote: > On Wed, 2013-01-02 at 13:29 -0800, Paul E. McKenney wrote: > > On Wed, Jan 02, 2013 at 03:56:30PM -0500, Steven Rostedt wrote: > > > On Wed, Jan 02, 2013 at 08:09:20PM +0100, Ralf Hildebrandt wrote: > > > > This happened of a virtual guest (Linux mail 3.2.0-35-virtual > > > > #55-Ubuntu SMP Wed Dec 5 18:02:05 UTC 2012 x86_64 x86_64 x86_64 > > > > GNU/Linux) > > > > > > 3.2 is rather old and this looks to be a stock Ubuntu kernel. May want > > > to file a Bugzilla (or whatever they call it) with them. > > > > > > > > > > > Jan 2 13:24:08 mail kernel: [3531872.484283] INFO: rcu_bh detected > > > > stall on CPU 3 (t=0 jiffies) > > > > > > 0 jiffies? > > > > One possibility is that they are missing commit a10d206e (rcu: Fix > > day-one dyntick-idle stall-warning bug), at least assuming that > > CONFIG_PREEMPT=n. This went into 3.6, IIRC. > > If that does fix the issue, we probably should send that off to Ben for > inclusion into 3.2 stable. Looks like you already CCed him, thank you! ;-) Thanx, Paul > Thanks, > > -- Steve > > > > > Thanx, Paul > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] mm: use mm_populate() when adjusting brk with MCL_FUTURE in effect.
On 12/20/2012 07:49 PM, Michel Lespinasse wrote: Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 0/8] Support for Tegra 2D hardware
On 01/02/2013 05:25 PM, Terje Bergström wrote:
> On 26.12.2012 11:42, Mark Zhang wrote:
[...]
>
>>
>> if (!de)
>> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
>> index 07e8813..01ed10d 100644
>> --- a/drivers/gpu/host1x/dev.c
>> +++ b/drivers/gpu/host1x/dev.c
>> @@ -38,6 +38,7 @@
>>
>> struct host1x *host1x;
>>
>> +/* Called by drm unlocked ioctl function. So do we need a lock here? */
>> void host1x_syncpt_incr_byid(u32 id)
>
> No, host1x_syncpt_incr_byid is SMP safe.
Correct. Lock is unnecessary.
>
>> {
>> struct host1x_syncpt *sp = host1x->syncpt + id;
>> @@ -52,6 +53,7 @@ u32 host1x_syncpt_read_byid(u32 id)
>> }
>> EXPORT_SYMBOL(host1x_syncpt_read_byid);
>>
>> +/* Called by drm unlocked ioctl function. So do we need a lock here? */
>> int host1x_syncpt_wait_byid(u32 id, u32 thresh, long timeout, u32 *value)
>
> Same here, SMP safe.
>
>> {
>> struct host1x_syncpt *sp = host1x->syncpt + id;
>> @@ -161,6 +163,8 @@ static int host1x_probe(struct platform_device *dev)
>>
>> err = host1x_alloc_resources(host);
>> if (err) {
>> + /* We don't have chip_ops right now, so here the
>> + error message is somewhat improper */
>> dev_err(&dev->dev, "failed to init chip support\n");
>> goto fail;
>> }
>
> Actually, alloc_resources only allocates intr->syncpt, so I the code to
> host1x_intr_init().
>
>> @@ -175,6 +179,14 @@ static int host1x_probe(struct platform_device *dev)
>> if (!host->syncpt)
>> goto fail;
>>
>> + /* I suggest create a dedicate function for initializing nop sp.
>> + First this "_host1x_syncpt_alloc" looks like an internal/static
>> + function.
>> + Then actually "host1x_syncpt_alloc" & "_host1x_syncpt_alloc" all
>> + serve host1x client(e.g: gr2d) so it's not suitable to use them
>> + for nop sp.
>> + Just create a wrapper function to call _host1x_syncpt_alloc is OK.
>> + This will make the code more readable. */
>> host->nop_sp = _host1x_syncpt_alloc(host, NULL, 0);
>
> _host1x_syncpt_alloc is an internal function, not exported.
> host1x_syncpt_alloc is exported. I think it's even better if I just move
> allocation of nop_sp to happen in host1x_syncpt_init.
>
Agree.
>> if (!host->nop_sp)
>> goto fail;
[...]
>
>> diff --git a/drivers/gpu/host1x/intr.c b/drivers/gpu/host1x/intr.c
>> index efcb9be..e112001 100644
>> --- a/drivers/gpu/host1x/intr.c
>> +++ b/drivers/gpu/host1x/intr.c
>> @@ -329,8 +329,13 @@ void host1x_intr_deinit(struct host1x_intr *intr)
>> void host1x_intr_start(struct host1x_intr *intr, u32 hz)
>> {
>> struct host1x *host1x = intr_to_host1x(intr);
>> +
>> + /* Why we need to lock here? Seems like this function is
>> + called by host1x's probe only. */
>> mutex_lock(&intr->mutex);
>>
>> + /* "init_host_sync" has already been called in function
>> + host1x_intr_init. Remove this line. */
>> host1x->intr_op.init_host_sync(intr);
>> host1x->intr_op.set_host_clocks_per_usec(intr,
>> DIV_ROUND_UP(hz, 100));
>
> In future, we'll call host1x_intr_start() whenever host1x is turned on.
> Thus we need locking.
>
> init_host_sync() should actually be called from host1x_intr_start(), not
> _init().
>
Got it. Thanks for explanation.
>> diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
>> index 07cbca5..9a234ad 100644
>> --- a/drivers/gpu/host1x/syncpt.c
>> +++ b/drivers/gpu/host1x/syncpt.c
>> @@ -309,6 +309,8 @@ struct host1x_syncpt *host1x_syncpt_init(struct
>> host1x *host)
>> struct host1x_syncpt *syncpt, *sp;
>> int i;
>>
>> + /* Consider devm_kzalloc here. Then you can forget the release
>> + stuffs about this "syncpt". */
>> syncpt = sp = kzalloc(sizeof(struct host1x_syncpt) *
>> host->info.nb_pts,
>> GFP_KERNEL);
>> if (!syncpt)
>
> Will do.
>
> Thanks!
>
> Terje
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lib: cpu_rmap: avoid flushing all workqueues
Thanks. It is not too late to review this code. But I'd prefer not to
address refactoring issues with this patch, which is supposed to fix a
deadlock with some drivers. So I'd rather not to add function
renaming, suppressions, etc. that have an effect outside cpu_rmap's
code. Instead, I'd like to propose another patch later, which will be
a little more intrusive in that respect, if that's ok with you.
I believe Ben answered your other concerns, I consider him as the
expert as to whether there should be finer-grained locking implemented
in this subsystem. Let me just add that I second him in saying that
the deadlock risk was clearly identified and mentioned in the doc.
Unfortunately, initial implementation makes this risk hard to
work-around for some drivers, which is what this patch proposes to
address.
So, for now, I'd like to keep v4 as the current version. And some
refactoring will be done in a later patch.
Regards,
--
David Decotigny
On Wed, Jan 2, 2013 at 3:12 PM, Andrew Morton wrote:
> On Wed, 2 Jan 2013 13:52:25 -0800
> David Decotigny wrote:
>
>> In some cases, free_irq_cpu_rmap() is called while holding a lock
>> (eg. rtnl). This can lead to deadlocks, because it invokes
>> flush_scheduled_work() which ends up waiting for whole system
>> workqueue to flush, but some pending works might try to acquire the
>> lock we are already holding.
>>
>> This commit uses reference-counting to replace
>> irq_run_affinity_notifiers(). It also removes
>> irq_run_affinity_notifiers() altogether.
>
> I can't say that I've ever noticed cpu_rmap.c before :( Is is too late
> to review it?
>
> - The naming is chaotic. At least these:
>
> EXPORT_SYMBOL(alloc_cpu_rmap);
> EXPORT_SYMBOL(free_cpu_rmap);
> EXPORT_SYMBOL(cpu_rmap_add);
> EXPORT_SYMBOL(cpu_rmap_update);
> EXPORT_SYMBOL(free_irq_cpu_rmap);
> EXPORT_SYMBOL(irq_cpu_rmap_add);
>
> should be consistently named cpu_rmap_foo()
>
> - What's the locking model? It appears to be caller-provided, but
> it is undocumented.
>
> drivers/net/ethernet/mellanox/mlx4/ appears to be using
> msix_ctl.pool_lock for exclusion, but I didn't check for coverage.
>
> drivers/net/ethernet/sfc/efx.c seems to not need locking because
> all its cpu_rmap operations are at module_init() time.
>
> The cpu_rmap code would be less of a hand grenade if each of its
> interface functions documented the caller's locking requirements.
>
>
> As for this patch: there's no cc:stable here but it does appear that
> the problem is sufficiently serious to justify a backport, agree?
>
>> --- a/include/linux/cpu_rmap.h
>> +++ b/include/linux/cpu_rmap.h
>>
>> ...
>>
>> @@ -33,15 +36,7 @@ struct cpu_rmap {
>> #define CPU_RMAP_DIST_INF 0x
>>
>> extern struct cpu_rmap *alloc_cpu_rmap(unsigned int size, gfp_t flags);
>> -
>> -/**
>> - * free_cpu_rmap - free CPU affinity reverse-map
>> - * @rmap: Reverse-map allocated with alloc_cpu_rmap(), or %NULL
>> - */
>> -static inline void free_cpu_rmap(struct cpu_rmap *rmap)
>> -{
>> - kfree(rmap);
>> -}
>> +extern void free_cpu_rmap(struct cpu_rmap *rmap);
>
> Can we do away with free_cpu_rmap() altogether? It is a misleading
> name - it is a put() function, not a free() function. It would be
> clearer (not to mention faster and smaller) to change all call sites
> to directly call cpu_rmap_put().
>
>
>> extern int cpu_rmap_add(struct cpu_rmap *rmap, void *obj);
>> extern int cpu_rmap_update(struct cpu_rmap *rmap, u16 index,
>>
>> ...
>>
>> @@ -63,6 +64,44 @@ struct cpu_rmap *alloc_cpu_rmap(unsigned int size, gfp_t
>> flags)
>> }
>> EXPORT_SYMBOL(alloc_cpu_rmap);
>>
>> +/**
>> + * cpu_rmap_reclaim - internal reclaiming helper called from kref_put
>> + * @ref: kref to struct cpu_rmap
>> + */
>> +static void cpu_rmap_reclaim(struct kref *ref)
>> +{
>> + struct cpu_rmap *rmap = container_of(ref, struct cpu_rmap, refcount);
>> + kfree(rmap);
>> +}
>
> I suggest this be renamed to cpu_rmap_release(). As "release" is the
> conventional term for a kref release handler.
>
>>
>> ...
>>
>> +/**
>> + * cpu_rmap_put - internal helper to release ref on a cpu_rmap
>> + * @rmap: reverse-map allocated with alloc_cpu_rmap()
>> + */
>> +static inline void cpu_rmap_put(struct cpu_rmap *rmap)
>> +{
>> + kref_put(&rmap->refcount, cpu_rmap_reclaim);
>> +}
>
> As mentioned, I suggest this become the public interface. And I
> suppose it should propagate kref_put()'s return value, in case someone
> is interested.
>
>> +/**
>> + * free_cpu_rmap - free CPU affinity reverse-map
>> + * @rmap: Reverse-map allocated with alloc_cpu_rmap()
>> + */
>> +void free_cpu_rmap(struct cpu_rmap *rmap)
>> +{
>> + cpu_rmap_put(rmap);
>> +}
>> +EXPORT_SYMBOL(free_cpu_rmap);
>
> zap.
>
>> /* Reevaluate nearest object for given CPU, comparing with the given
>> * neighbours at the given distance.
>> */
>>
>> ...
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: linux-next: Tree for Jan 2 (netfilter)
On Thu, Jan 03, 2013 at 02:35:59AM +0100, Pablo Neira Ayuso wrote: > > when NF_CONNTRACK is not enabled (build was on i386): > > > > CC [M] net/netfilter/xt_CT.o > > In file included from net/netfilter/xt_CT.c:16:0: > > include/net/netfilter/nf_conntrack.h:77:22: error: field 'ct_general' has > > incomplete type > > include/net/netfilter/nf_conntrack.h: In function 'nf_ct_get': > > include/net/netfilter/nf_conntrack.h:157:30: error: 'const struct sk_buff' > > has no member named 'nfct' > > include/net/netfilter/nf_conntrack.h: In function 'nf_ct_put': > > include/net/netfilter/nf_conntrack.h:164:2: error: implicit declaration of > > function 'nf_conntrack_put' [-Werror=implicit-function-declaration] > > net/netfilter/xt_CT.c: In function 'xt_ct_target_v0': > > net/netfilter/xt_CT.c:30:9: error: 'struct sk_buff' has no member named > > 'nfct' > > net/netfilter/xt_CT.c:34:5: error: 'struct sk_buff' has no member named > > 'nfct' > > net/netfilter/xt_CT.c: In function 'xt_ct_target_v1': > > net/netfilter/xt_CT.c:47:9: error: 'struct sk_buff' has no member named > > 'nfct' > > net/netfilter/xt_CT.c:51:5: error: 'struct sk_buff' has no member named > > 'nfct' > > net/netfilter/xt_CT.c: In function 'xt_ct_tg_check_v0': > > net/netfilter/xt_CT.c:155:15: error: 'struct net' has no member named 'ct' > > net/netfilter/xt_CT.c: In function 'xt_ct_tg_check_v1': > > net/netfilter/xt_CT.c:299:15: error: 'struct net' has no member named 'ct' > > net/netfilter/xt_CT.c: In function 'notrack_tg': > > net/netfilter/xt_CT.c:392:9: error: 'struct sk_buff' has no member named > > 'nfct' > > net/netfilter/xt_CT.c:395:5: error: 'struct sk_buff' has no member named > > 'nfct' > > net/netfilter/xt_CT.c:397:2: error: implicit declaration of function > > 'nf_conntrack_get' [-Werror=implicit-function-declaration] > > net/netfilter/xt_CT.c:397:22: error: 'struct sk_buff' has no member named > > 'nfct' > > cc1: some warnings being treated as errors > > make[3]: *** [net/netfilter/xt_CT.o] Error 1 > > Sorry, I cannot reproduce the selection ... Caught it. Patch attached, thanks for the report. >From b8198d1ee451c00c2fd660202ad68580c35e1dd8 Mon Sep 17 00:00:00 2001 From: Pablo Neira Ayuso Date: Thu, 3 Jan 2013 03:22:36 +0100 Subject: [PATCH] netfilter: fix missing dependencies for the NOTRACK target warning: (NETFILTER_XT_TARGET_NOTRACK) selects NETFILTER_XT_TARGET_CT which has unmet direct +dependencies (NET && INET && NETFILTER && NETFILTER_XTABLES && NF_CONNTRACK && (IP_NF_RAW || +IP6_NF_RAW) && NETFILTER_ADVANCED) Reported-by: Randy Dunlap Reported-by: kbuild test robot Signed-off-by: Pablo Neira Ayuso --- net/netfilter/Kconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index 390f96c..49e96df 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -682,6 +682,9 @@ config NETFILTER_XT_TARGET_NFQUEUE config NETFILTER_XT_TARGET_NOTRACK tristate '"NOTRACK" target support (DEPRECATED)' + depends on NF_CONNTRACK + depends on IP_NF_RAW || IP6_NF_RAW + depends on NETFILTER_ADVANCED select NETFILTER_XT_TARGET_CT config NETFILTER_XT_TARGET_RATEEST -- 1.7.10.4
Re: [PATCH 06/13] cpuset: cleanup cpuset[_can]_attach()
Hello, Rusty. On Thu, Jan 03, 2013 at 11:17:11AM +1030, Rusty Russell wrote: > > So, I guess this currently is caught in a place which isn't here or > > there. I'm pretty skeptical whether it makes sense to bother about > > static usages tho. Can I keep them for static ones? > > I didn't realize that cpuset_attach was a fastpath. If it is, put a It isn't a hot path. It's just a bit nasty to have to allocate them separately. > static there and I'll fix turn it into a bitmap when I need to. > Otherwise, please don't change the code in the first place. So, the plan to drop cpumask_t is still on? If so, I'll leave cpumask_var_t. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] mm: use mm_populate() for blocking remap_file_pages()
On 12/20/2012 07:49 PM, Michel Lespinasse wrote: Signed-off-by: Michel Lespinasse Changelog could use some help :) Other than that: Reviewed-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] mm: introduce mm_populate() for populating new vmas
On 12/20/2012 07:49 PM, Michel Lespinasse wrote: When creating new mappings using the MAP_POPULATE / MAP_LOCKED flags (or with MCL_FUTURE in effect), we want to populate the pages within the newly created vmas. This may take a while as we may have to read pages from disk, so ideally we want to do this outside of the write-locked mmap_sem region. This change introduces mm_populate(), which is used to defer populating such mappings until after the mmap_sem write lock has been released. This is implemented as a generalization of the former do_mlock_pages(), which accomplished the same task but was using during mlock() / mlockall(). Reported-by: Andy Lutomirski Signed-off-by: Michel Lespinasse Acked-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/7] leds: leds-pwm: Device tree support
Hi Peter, I merged this patchset into my for-next branch already. Thanks for pushing this. -Bryan On Fri, Dec 21, 2012 at 1:43 AM, Peter Ujfalusi wrote: > Hello, > > Changes since v4: > - Commit message for patch #7 (DT binding for the leds-pwm driver) has been > updated > > Changes since v3: > Addressed comments from Thierry Redding: > - DT binding documentation for leds-pwm updated > - of_pwm_request() renamed as of_pwm_get() > - introduction of devm_of_pwm_get() > - Commit message updates > - Other comments has been also addressed > - Acked-by from Grant is not added to the patches since they were modified > since > v3 > > Changes since v2: > - rebased on top of linux-next > - DT bindings now alligned with Grant's request > - exporting of_pwm_request() from PWM core to allow clean DT bindings > - DT binding documentation changed to reflect the changes > > Changes since v1: > - As suggested by Bryan Wu: the legacy pwm_request() has been removed from > patch 1 > - Device tree bindings added for leds-pwm driver. > > When we boot with Device tree we handle one LED per device to be more aligned > with PWM core's DT implementation. > An example of the DT usage is provided in the new DT binding documentation for > leds-pwm. > > Tested on OMAP4 Blaze (SDP), BeagleBoard with legacy and DT boot. On Zoom2 > with > legacy boot. > > Regards, > Peter > --- > Peter Ujfalusi (7): > leds: leds-pwm: Convert to use devm_get_pwm > leds: leds-pwm: Preparing the driver for device tree support > pwm: Correct parameter name in header for *pwm_get() functions > pwm: core: Rename of_pwm_request() to of_pwm_get() and export it > pwm: Add devm_of_pwm_get() as exported API for users > leds: leds-pwm: Simplify cleanup code > leds: leds-pwm: Add device tree bindings > > .../devicetree/bindings/leds/leds-pwm.txt | 48 +++ > drivers/leds/leds-pwm.c| 152 > +++-- > drivers/pwm/core.c | 38 +- > include/linux/leds_pwm.h | 2 +- > include/linux/pwm.h| 20 ++- > 5 files changed, 212 insertions(+), 48 deletions(-) > create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.txt > > -- > 1.8.0.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] a LED fix for 3.8 (try2)
Hi Linus: Please consider the following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565: Linux 3.8-rc1 (2012-12-21 17:19:00 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git for you to fetch changes up to 2d7c22f67d5c342a6296127af4f224208449b779: leds: leds-gpio: set devm_gpio_request_one() flags param correctly (2013-01-02 17:58:41 -0800) Javier Martinez Canillas (1): leds: leds-gpio: set devm_gpio_request_one() flags param correctly drivers/leds/leds-gpio.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] a LED fix for 3.8
Sorry, I signed off with wrong email address. Please ignore this pull request email. I will resent one. -Bryan On Wed, Jan 2, 2013 at 5:50 PM, Bryan Wu wrote: > Hi Linus: > > Please consider the following changes since commit > a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565: > > Linux 3.8-rc1 (2012-12-21 17:19:00 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git > fixes-for-3.8 > > for you to fetch changes up to c36f03f2c4b6c02166a217a71e072603ee33423e: > > leds: leds-gpio: set devm_gpio_request_one() flags param correctly > (2013-01-02 17:03:49 -0800) > > > Javier Martinez Canillas (1): > leds: leds-gpio: set devm_gpio_request_one() flags param correctly > > drivers/leds/leds-gpio.c |5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] a LED fix for 3.8
Hi Linus: Please consider the following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565: Linux 3.8-rc1 (2012-12-21 17:19:00 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git fixes-for-3.8 for you to fetch changes up to c36f03f2c4b6c02166a217a71e072603ee33423e: leds: leds-gpio: set devm_gpio_request_one() flags param correctly (2013-01-02 17:03:49 -0800) Javier Martinez Canillas (1): leds: leds-gpio: set devm_gpio_request_one() flags param correctly drivers/leds/leds-gpio.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI / scan: Do not use dummy HID for system bus ACPI nodes
From: Rafael J. Wysocki
At one point acpi_device_set_id() checks if acpi_device_hid(device)
returns NULL, but that never happens, so system bus devices with an
empty list of PNP IDs are given the dummy HID ("device") instead of
the "system bus HID" ("LNXSYBUS"). Fix the code to use the right
check.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1398,7 +1398,7 @@ static void acpi_device_set_id(struct ac
acpi_add_id(device, ACPI_DOCK_HID);
else if (!acpi_ibm_smbus_match(device))
acpi_add_id(device, ACPI_SMBUS_IBM_HID);
- else if (!acpi_device_hid(device) &&
+ else if (list_empty(&device->pnp.ids) &&
ACPI_IS_ROOT_DEVICE(device->parent)) {
acpi_add_id(device, ACPI_BUS_HID); /* \_SB, LNXSYBUS */
strcpy(device->pnp.device_name, ACPI_BUS_DEVICE_NAME);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 2 (netfilter)
Hi, On Wed, Jan 02, 2013 at 10:39:43AM -0800, Randy Dunlap wrote: > On 01/01/13 20:12, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20121224: > > > > when NF_CONNTRACK is not enabled (build was on i386): > > CC [M] net/netfilter/xt_CT.o > In file included from net/netfilter/xt_CT.c:16:0: > include/net/netfilter/nf_conntrack.h:77:22: error: field 'ct_general' has > incomplete type > include/net/netfilter/nf_conntrack.h: In function 'nf_ct_get': > include/net/netfilter/nf_conntrack.h:157:30: error: 'const struct sk_buff' > has no member named 'nfct' > include/net/netfilter/nf_conntrack.h: In function 'nf_ct_put': > include/net/netfilter/nf_conntrack.h:164:2: error: implicit declaration of > function 'nf_conntrack_put' [-Werror=implicit-function-declaration] > net/netfilter/xt_CT.c: In function 'xt_ct_target_v0': > net/netfilter/xt_CT.c:30:9: error: 'struct sk_buff' has no member named 'nfct' > net/netfilter/xt_CT.c:34:5: error: 'struct sk_buff' has no member named 'nfct' > net/netfilter/xt_CT.c: In function 'xt_ct_target_v1': > net/netfilter/xt_CT.c:47:9: error: 'struct sk_buff' has no member named 'nfct' > net/netfilter/xt_CT.c:51:5: error: 'struct sk_buff' has no member named 'nfct' > net/netfilter/xt_CT.c: In function 'xt_ct_tg_check_v0': > net/netfilter/xt_CT.c:155:15: error: 'struct net' has no member named 'ct' > net/netfilter/xt_CT.c: In function 'xt_ct_tg_check_v1': > net/netfilter/xt_CT.c:299:15: error: 'struct net' has no member named 'ct' > net/netfilter/xt_CT.c: In function 'notrack_tg': > net/netfilter/xt_CT.c:392:9: error: 'struct sk_buff' has no member named > 'nfct' > net/netfilter/xt_CT.c:395:5: error: 'struct sk_buff' has no member named > 'nfct' > net/netfilter/xt_CT.c:397:2: error: implicit declaration of function > 'nf_conntrack_get' [-Werror=implicit-function-declaration] > net/netfilter/xt_CT.c:397:22: error: 'struct sk_buff' has no member named > 'nfct' > cc1: some warnings being treated as errors > make[3]: *** [net/netfilter/xt_CT.o] Error 1 Sorry, I cannot reproduce the selection that your config file contains: CONFIG_NF_CONNTRACK=n NETFILTER_XT_TARGET_CT=m after make oldconfig is run. NETFILTER_XT_TARGET_CT already depends on NF_CONNTRACK in our Kconfig, so I don't see what can be bad yet. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the pinctrl tree with the driver-core.current tree
Hi Linus,
Today's linux-next merge of the pinctrl tree got a conflict in
drivers/pinctrl/pinctrl-nomadik.c between commit c2c57b329c7b ("Drivers:
pinctrl: remove __dev* attributes") from the driver-core.current tree and
commit f7ae849b80de ("pinctrl/nomadik: adopt pinctrl sleep mode
management") from the pinctrl tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/pinctrl/pinctrl-nomadik.c
index c68ec40,8e4720f..000
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@@ -1846,7 -2111,29 +2111,29 @@@ static const struct of_device_id nmk_pi
{},
};
+ static int nmk_pinctrl_suspend(struct platform_device *pdev, pm_message_t
state)
+ {
+ struct nmk_pinctrl *npct;
+
+ npct = platform_get_drvdata(pdev);
+ if (!npct)
+ return -EINVAL;
+
+ return pinctrl_force_sleep(npct->pctl);
+ }
+
+ static int nmk_pinctrl_resume(struct platform_device *pdev)
+ {
+ struct nmk_pinctrl *npct;
+
+ npct = platform_get_drvdata(pdev);
+ if (!npct)
+ return -EINVAL;
+
+ return pinctrl_force_default(npct->pctl);
+ }
+
-static int __devinit nmk_pinctrl_probe(struct platform_device *pdev)
+static int nmk_pinctrl_probe(struct platform_device *pdev)
{
const struct platform_device_id *platid = platform_get_device_id(pdev);
struct device_node *np = pdev->dev.of_node;
pgpQ85fNI.pgp
Description: PGP signature
Re: [PATCH] module: prevent warning when finit_module a 0 sized file
Sasha Levin writes:
> If we try to finit_module on a file sized 0 bytes vmalloc will
> scream and spit out a warning.
>
> Since modules have to be bigger than 0 bytes anyways we can just
> check that beforehand and avoid the warning.
Applied, but I added the comment you somehow missed :)
Thanks,
Rusty.
diff --git a/kernel/module.c b/kernel/module.c
index 250092c..41bc118 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2527,6 +2527,13 @@ static int copy_module_from_fd(int fd, struct load_info
*info)
err = -EFBIG;
goto out;
}
+
+ /* Don't hand 0 to vmalloc, it whines. */
+ if (stat.size == 0) {
+ err = -EINVAL;
+ goto out;
+ }
+
info->hdr = vmalloc(stat.size);
if (!info->hdr) {
err = -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modpost: Add flag -f for making section mismatches fatal
Jonathan Kliegman writes: > The section mismatch warning can be easy to miss during the kernel build > process. Allow it to be marked as fatal to be easily caught and prevent > bugs from slipping in. > > Signed-off-by: Jonathan Kliegman Hmm, a CONFIG option with no Kconfig entry? That seems weird... Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/13] cpuset: cleanup cpuset[_can]_attach()
Tejun Heo writes: > Hello, Rusty. > > On Wed, Jan 02, 2013 at 03:12:15PM +1030, Rusty Russell wrote: >> > Hmmm? cpumask_t can't be used for stack but other than that I don't >> > see how it would be deprecated completely. Rusty, can you please >> > chime in? >> >> The long-never-quite-complete-plan was for struct cpumask to be >> undefined when CONFIG_CPUMASK_OFFSTACK=y. That means noone can declare >> them, or pass them on the stack, since they'll get a compiler error. >> >> Now, there are some cases where it really is a reason to use a static >> bitmap, and 1/2 a K of wasted space be damned. There's a >> deliberately-ugly way of doing that: declare a bitmap and use >> to_cpumask(). Of course, if we ever really want to remove NR_CPUS and >> make it completely generic, we have to kill all these too, but noone is >> serious about that. > > So, I guess this currently is caught in a place which isn't here or > there. I'm pretty skeptical whether it makes sense to bother about > static usages tho. Can I keep them for static ones? I didn't realize that cpuset_attach was a fastpath. If it is, put a static there and I'll fix turn it into a bitmap when I need to. Otherwise, please don't change the code in the first place. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] module: add syscall to load module from fd
Michael Kerrisk writes: > Hi Rusty, Hi Michael, > The description here is rather thin. Could you supply a sentence or > two for each of MODULE_INIT_IGNORE_MODVERSIONS and > MODULE_INIT_IGNORE_VERMAGIC that would be suitable for the manual > page? > > Thanks, There are one or two safety checks built into a module, which are checked to match the kernel on module load. The first is a "vermagic" string containing the kernel version number and prominent features (such as CPU type). If the module was built with CONFIG_MODVERSIONS set, a version hash is recorded for each symbol the module uses based on the types it refers to: in this case, the kernel version number within the "vermagic" string is ignored, as the symbol version hashes are assumed to be sufficiently reliable. Using the MODULE_INIT_IGNORE_VERMAGIC flag indicates that the vermagic is to be ignored, and the MODULE_INIT_IGNORE_MODVERSIONS flag indicates that the version hashes are to be ignored. If the kernel is built to permit such forced loading (ie. CONFIG_MODULE_FORCE_LOAD is set) then loading will continue, otherwise it will fail with ENOEXEC as expected for malformed modules. Hope that is more usable? Thanks, Rusty, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] cpufreq: Manage only online cpus
On Wednesday, January 02, 2013 11:59:57 AM Viresh Kumar wrote: > On 16 December 2012 19:07, Viresh Kumar wrote: > > On 16 December 2012 18:34, Rafael J. Wysocki wrote: > > >> Well, this series makes sense to me, but I'd like to hear what the other > >> people > >> think. > > > > That sounds great :) > > > > Some more information for others about how i reached to these issues > > is present here: > > > > https://lkml.org/lkml/2012/12/10/44 > > Hmm.. I don't know, if we are going to get any feedback from others :( Surely somebody cares except for us two? > BTW, i consider them as fixes and so would make sense to get them in next rc. > What do you think? Yes, if somebody tells me "yes, this fixes a problem for me". Otherwise, I don't quite see the reason. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvm tree with the s390 tree
Hi all,
Today's linux-next merge of the kvm tree got conflicts in
arch/s390/include/asm/irq.h and arch/s390/kernel/irq.c between commit
bfb048f594d5 ("s390/irq: remove split irq fields from /proc/stat") from
the s390 tree and commit 7e64e0597fd6 ("KVM: s390: Add a channel I/O
based virtio transport driver") from the kvm tree.
I fixed it up (I think - see below) including the following merge fix
patch and can carry the fix as necessary (more action may be required).
From: Stephen Rothwell
Date: Thu, 3 Jan 2013 12:04:39 +1100
Subject: [PATCH] KVM: s390: fix for IOINT_VIR name change
Signed-off-by: Stephen Rothwell
---
drivers/s390/kvm/virtio_ccw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
index 1a5aff3..f94a0b1 100644
--- a/drivers/s390/kvm/virtio_ccw.c
+++ b/drivers/s390/kvm/virtio_ccw.c
@@ -745,7 +745,7 @@ static struct ccw_driver virtio_ccw_driver = {
.set_offline = virtio_ccw_offline,
.set_online = virtio_ccw_online,
.notify = virtio_ccw_cio_notify,
- .int_class = IOINT_VIR,
+ .int_class = IRQIO_VIR,
};
static int __init pure_hex(char **cp, unsigned int *val, int min_digit,
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/s390/include/asm/irq.h
index 7def773,aa6d0d7..000
--- a/arch/s390/include/asm/irq.h
+++ b/arch/s390/include/asm/irq.h
@@@ -2,61 -2,44 +2,62 @@@
#define _ASM_IRQ_H
#include
+#include
+#include
#include
-enum interruption_class {
+enum interruption_main_class {
EXTERNAL_INTERRUPT,
IO_INTERRUPT,
- EXTINT_CLK,
- EXTINT_EXC,
- EXTINT_EMS,
- EXTINT_TMR,
- EXTINT_TLA,
- EXTINT_PFL,
- EXTINT_DSD,
- EXTINT_VRT,
- EXTINT_SCP,
- EXTINT_IUC,
- EXTINT_CMS,
- EXTINT_CMC,
- EXTINT_CMR,
- IOINT_CIO,
- IOINT_QAI,
- IOINT_DAS,
- IOINT_C15,
- IOINT_C70,
- IOINT_TAP,
- IOINT_VMR,
- IOINT_LCS,
- IOINT_CLW,
- IOINT_CTC,
- IOINT_APB,
- IOINT_ADM,
- IOINT_CSC,
- IOINT_PCI,
- IOINT_MSI,
- IOINT_VIR,
+ NR_IRQS
+};
+
+enum interruption_class {
+ IRQEXT_CLK,
+ IRQEXT_EXC,
+ IRQEXT_EMS,
+ IRQEXT_TMR,
+ IRQEXT_TLA,
+ IRQEXT_PFL,
+ IRQEXT_DSD,
+ IRQEXT_VRT,
+ IRQEXT_SCP,
+ IRQEXT_IUC,
+ IRQEXT_CMS,
+ IRQEXT_CMC,
+ IRQEXT_CMR,
+ IRQIO_CIO,
+ IRQIO_QAI,
+ IRQIO_DAS,
+ IRQIO_C15,
+ IRQIO_C70,
+ IRQIO_TAP,
+ IRQIO_VMR,
+ IRQIO_LCS,
+ IRQIO_CLW,
+ IRQIO_CTC,
+ IRQIO_APB,
+ IRQIO_ADM,
+ IRQIO_CSC,
+ IRQIO_PCI,
+ IRQIO_MSI,
++ IRQIO_VIR,
NMI_NMI,
- NR_IRQS,
+ CPU_RST,
+ NR_ARCH_IRQS
};
+struct irq_stat {
+ unsigned int irqs[NR_ARCH_IRQS];
+};
+
+DECLARE_PER_CPU_SHARED_ALIGNED(struct irq_stat, irq_stat);
+
+static __always_inline void inc_irq_stat(enum interruption_class irq)
+{
+ __get_cpu_var(irq_stat).irqs[irq]++;
+}
+
struct ext_code {
unsigned short subcode;
unsigned short code;
diff --cc arch/s390/kernel/irq.c
index 9df824e,a9806ea..000
--- a/arch/s390/kernel/irq.c
+++ b/arch/s390/kernel/irq.c
@@@ -32,57 -29,39 +32,58 @@@ struct irq_class
char *desc;
};
-static const struct irq_class intrclass_names[] = {
+/*
+ * The list of "main" irq classes on s390. This is the list of interrrupts
+ * that appear both in /proc/stat ("intr" line) and /proc/interrupts.
+ * Historically only external and I/O interrupts have been part of /proc/stat.
+ * We can't add the split external and I/O sub classes since the first field
+ * in the "intr" line in /proc/stat is supposed to be the sum of all other
+ * fields.
+ * Since the external and I/O interrupt fields are already sums we would end
+ * up with having a sum which accounts each interrupt twice.
+ */
+static const struct irq_class irqclass_main_desc[NR_IRQS] = {
[EXTERNAL_INTERRUPT] = {.name = "EXT"},
- [IO_INTERRUPT] = {.name = "I/O"},
- [EXTINT_CLK] = {.name = "CLK", .desc = "[EXT] Clock Comparator"},
- [EXTINT_EXC] = {.name = "EXC", .desc = "[EXT] External Call"},
- [EXTINT_EMS] = {.name = "EMS", .desc = "[EXT] Emergency Signal"},
- [EXTINT_TMR] = {.name = "TMR", .desc = "[EXT] CPU Timer"},
- [EXTINT_TLA] = {.name = "TAL", .desc = "[EXT] Timing Alert"},
- [EXTINT_PFL] = {.name = "PFL", .desc = "[EXT] Pseudo Page Fault"},
- [EXTINT_DSD] = {.name = "DSD", .desc = "[EXT] DASD Diag"},
- [EXTINT_VRT] = {.name = "VRT", .desc = "[EXT] Virtio"},
- [EXTINT_SCP] = {.name = "SCP", .desc = "[EXT] Service Call"},
- [EXTINT_IUC] = {.name = "IUC", .desc = "[EXT] IUCV"},
- [EXTINT_CMS] = {.name = "CMS", .desc = "[EXT] CPU-Measureme
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 2, 2013 at 4:59 PM, Alex Deucher wrote: >>> >> >> Catching up with this thread. I reverted the >> >> drm/radeon: use async dma for ttm buffer moves on 6xx-SI >> commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 >> >> Do I need to apply this patch without reverting >> 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? > > Correct. Don't revert anything. Just apply this patch. > > Alex Alex, Your patch fixed the problem I was seeing. -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 01/03/2013 01:59 AM, Alex Deucher wrote: On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote: On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c is : .copy = &r600_copy_dma, .copy_ring_index = R600_RING_TYPE_DMA_INDEX, It fixes the issue for me. Thanks. The count is actually the count, not count - 1. The real fix seems to be that r6xx requires 2 dw aligned transfers. The attached patch fixes the issue for me. Catching up with this thread. I reverted the drm/radeon: use async dma for ttm buffer moves on 6xx-SI commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 Do I need to apply this patch without reverting 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? Correct. Don't revert anything. Just apply this patch. Tested, it is working. I didn't revert anything, just added that latest patch. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: INFO: rcu_bh detected stall on CPU 3 (t=0 jiffies)
On Wed, 2013-01-02 at 13:29 -0800, Paul E. McKenney wrote: > On Wed, Jan 02, 2013 at 03:56:30PM -0500, Steven Rostedt wrote: > > On Wed, Jan 02, 2013 at 08:09:20PM +0100, Ralf Hildebrandt wrote: > > > This happened of a virtual guest (Linux mail 3.2.0-35-virtual #55-Ubuntu > > > SMP Wed Dec 5 18:02:05 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux) > > > > 3.2 is rather old and this looks to be a stock Ubuntu kernel. May want > > to file a Bugzilla (or whatever they call it) with them. > > > > > > > > Jan 2 13:24:08 mail kernel: [3531872.484283] INFO: rcu_bh detected stall > > > on CPU 3 (t=0 jiffies) > > > > 0 jiffies? > > One possibility is that they are missing commit a10d206e (rcu: Fix > day-one dyntick-idle stall-warning bug), at least assuming that > CONFIG_PREEMPT=n. This went into 3.6, IIRC. If that does fix the issue, we probably should send that off to Ben for inclusion into 3.2 stable. Thanks, -- Steve > > Thanx, Paul > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] tracing: Verify target file before registering a uprobe event
From: Jovi Zhang
Without this patch, we can register a uprobe event for a directory.
Enabling such a uprobe event would fail anyway .
Example:
$ echo 'p /bin:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
However dirctories cannot be valid targets for uprobe.
Hence verify if the target is a regular file during the probe
registration.
Signed-off-by: Jovi Zhang
Acked-by: Srikar Dronamraju
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_uprobe.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 03003cd..0815f25 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -257,6 +257,10 @@ static int create_trace_uprobe(int argc, char **argv)
goto fail_address_parse;
inode = igrab(path.dentry->d_inode);
+if (!S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode)) {
+ ret = -EINVAL;
+ goto fail_address_parse;
+ }
argc -= 2;
argv += 2;
@@ -356,7 +360,7 @@ fail_address_parse:
if (inode)
iput(inode);
- pr_info("Failed to parse address.\n");
+ pr_info("Failed to parse address or file.\n");
return ret;
}
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 2/3] tracing: Fix sparse warning with is_signed_type() macro
From: Steven Rostedt Sparse complains when is_signed_type() is used on a pointer. This macro is needed for the format output used for ftrace and perf, to know if a binary field is a signed type or not. The is_signed_type() macro is used against all fields that are recorded by events to automate the operation. The problem sparse has is with the current way is_signed_type() works: ((type)-1 < 0) If "type" is a poiner, than sparse does not like it being compared to an integer (zero). The simple fix is to just give zero the same type. The runtime result stays the same. Reported-by: Robert Jarzmik Signed-off-by: Steven Rostedt --- include/linux/ftrace_event.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h index 642928c..cc87955 100644 --- a/include/linux/ftrace_event.h +++ b/include/linux/ftrace_event.h @@ -266,7 +266,7 @@ extern int trace_define_field(struct ftrace_event_call *call, const char *type, extern int trace_add_event_call(struct ftrace_event_call *call); extern void trace_remove_event_call(struct ftrace_event_call *call); -#define is_signed_type(type) (((type)(-1)) < 0) +#define is_signed_type(type) (((type)(-1)) < (type)0) int trace_set_clr_event(const char *system, const char *event, int set); -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
[PATCH 0/3] [GIT PULL][3.8] tracing: Minor fixes for 3.8
Ingo, As it's still an early -rc, it would be good to get these fixes into mainline before the next release. Thanks, -- Steve Please pull the latest tip/perf/urgent tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git tip/perf/urgent Head SHA1: f9dd9809c1426ccc7e997201b9b839c96ac810ec Jovi Zhang (1): tracing: Verify target file before registering a uprobe event Steven Rostedt (2): ftrace: Be first to run code modification on modules tracing: Fix sparse warning with is_signed_type() macro include/linux/ftrace_event.h |2 +- kernel/trace/ftrace.c|2 +- kernel/trace/trace_uprobe.c |6 +- 3 files changed, 7 insertions(+), 3 deletions(-) signature.asc Description: This is a digitally signed message part
[PATCH 1/3] ftrace: Be first to run code modification on modules
From: Steven Rostedt
If some other kernel subsystem has a module notifier, and adds a kprobe
to a ftrace mcount point (now that kprobes work on ftrace points),
when the ftrace notifier runs it will fail and disable ftrace, as well
as kprobes that are attached to ftrace points.
Here's the error:
WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280()
Hardware name: Bochs
Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4
auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc
parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last
unloaded: bid_shared]
Pid: 8068, comm: modprobe Tainted: GF
3.7.0-0.rc8.git0.1.fc19.x86_64 #1
Call Trace:
[] warn_slowpath_common+0x7f/0xc0
[] ? __probe_kernel_read+0x46/0x70
[] ? 0xa017
[] ? 0xa017
[] warn_slowpath_null+0x1a/0x20
[] ftrace_bug+0x239/0x280
[] ftrace_process_locs+0x376/0x520
[] ftrace_module_notify+0x47/0x50
[] notifier_call_chain+0x4d/0x70
[] __blocking_notifier_call_chain+0x58/0x80
[] blocking_notifier_call_chain+0x16/0x20
[] sys_init_module+0x73/0x220
[] system_call_fastpath+0x16/0x1b
---[ end trace 9ef46351e53bbf80 ]---
ftrace failed to modify [] init_once+0x0/0x20 [fat]
actual: cc:bb:d2:4b:e1
A kprobe was added to the init_once() function in the fat module on load.
But this happened before ftrace could have touched the code. As ftrace
didn't run yet, the kprobe system had no idea it was a ftrace point and
simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1).
Then when ftrace went to modify the location from a call to mcount/fentry
into a nop, it didn't see a call op, but instead it saw the breakpoint op
and not knowing what to do with it, ftrace shut itself down.
The solution is to simply give the ftrace module notifier the max priority.
This should have been done regardless, as the core code ftrace modification
also happens very early on in boot up. This makes the module modification
closer to core modification.
Cc: Masami Hiramatsu
Reported-by: Frank Ch. Eigler
Signed-off-by: Steven Rostedt
---
kernel/trace/ftrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 51b7159..356bc2f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3998,7 +3998,7 @@ static int ftrace_module_notify(struct notifier_block
*self,
struct notifier_block ftrace_module_nb = {
.notifier_call = ftrace_module_notify,
- .priority = 0,
+ .priority = INT_MAX,/* Run before anything that can use kprobes */
};
extern unsigned long __start_mcount_loc[];
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] checkpatch: prefer dev_( to dev_printk(KERN_
On Wed, 2013-01-02 at 18:34 -0600, Bjorn Helgaas wrote:
> On Wed, Jan 2, 2013 at 6:06 PM, Joe Perches wrote:
> > Add YA check to printk style.
> >
> > dev_ uses are functions and generate smaller
> > object code than dev_printk(KERN_.
[]
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> > @@ -2430,6 +2430,16 @@ sub process {
> > "Prefer pr_warn(... to pr_warning(...\n" .
> > $herecurr);
> > }
> >
> > + if ($line =~ /\bdev_printk\s*\(\s*KERN_([A-Z]+)/) {
> > + my $orig = $1;
> > + my $level = lc($orig);
> > + $level = "warn" if ($level eq "warning");
> > + my $level2 = $level;
> > + $level2 = "dbg" if ($level eq "debug");
> > + WARN("PREFER_DEV_LEVEL",
> > +"Prefer dev_$level2(... to
> > dev_printk(KERN_$orig, ...\n" . $herecurr);
>
> This suggests dev_dbg() instead of dev_printk(KERN_DEBUG), doesn't it?
> Those aren't equivalent (dev_printk() always does the printk, but in
> many cases dev_dbg() does not, depending on CONFIG_DEBUG,
> CONFIG_DYNAMIC_DEBUG, etc.)
True, I think the suggested change is appropriate though.
If people really want debug output in a specific file,
then they should #define DEBUG and/or enable dynamic debug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nfsd: Don't unlock the state while it's not locked
On Mon, Dec 24, 2012 at 06:11:45PM +0800, ycn...@gmail.com wrote:
> From: Yanchuan Nian
>
> In the procedure of CREATE_SESSION, the state is locked after
> alloc_conn_from_crses(). If the allocation fails, the function
> goes to "out_free_session", and then "out" where there is an
> unlock function.
Thanks, applying for 3.9.--b.
>
> Signed-off-by: Yanchuan Nian
>
> ---
> fs/nfsd/nfs4state.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 29924a0..cc41bf4 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -1844,11 +1844,12 @@ nfsd4_create_session(struct svc_rqst *rqstp,
>
> /* cache solo and embedded create sessions under the state lock */
> nfsd4_cache_create_session(cr_ses, cs_slot, status);
> -out:
> nfs4_unlock_state();
> +out:
> dprintk("%s returns %d\n", __func__, ntohl(status));
> return status;
> out_free_conn:
> + nfs4_unlock_state();
> free_conn(conn);
> out_free_session:
> __free_session(new);
> --
> 1.7.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Alternative 2][PATCH] ACPI / PCI: Set root bridge ACPI handle in advance
On Wednesday, January 02, 2013 04:07:32 PM Bjorn Helgaas wrote: > On Thu, Dec 27, 2012 at 10:32:13PM +0100, Rafael J. Wysocki wrote: > > To that end, split pci_create_root_bus() into two functions, > > pci_alloc_root() and pci_add_root(), that will allocate memory for > > the new PCI bus and bridge representations and register them with > > the driver core, respectively, and that may be called directly by > > the architectures that need to set the root bridge's ACPI handle > > before registering it. > > I'm trying to *reduce* the interfaces for creating and scanning PCI > host bridges, and this is a step in the opposite direction. Yes it is. The alternative is to make the root bridge initialization code more complex. > > Next, Make both x86 and ia64 (the only architectures using ACPI at > > the moment) call pci_alloc_root(), set the root bridge's ACPI handle > > and then call pci_add_root() in their pci_acpi_scan_root() routines > > instead of calling pci_create_root_bus(). For the other code paths > > adding PCI root bridges define a new pci_create_root_bus() as a > > simple combination of pci_alloc_root() and pci_add_root(). > > pci_create_root_bus() takes a "struct device *parent" argument. That > seems like a logical place to tell the PCI core about the host bridge > device, but x86 and ia64 currently pass NULL there. And there's a reason for that. Namely, on these architectures PCI host bridges have no physical parents (well, at least in current practice). > The patch below shows what I'm thinking. It does have the side-effect > of changing the sysfs topology from this: > > /sys/devices/pci:00 > /sys/devices/pci:00/:00:00.0 > > to this: > > /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/pci:00 > /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/pci:00/:00:00.0 > > because it puts the PCI root bus (pci:00) under the PNP0A08 device > rather than at the top level. Which is wrong. PNP0A08 is not a parent of the host bridge, but its ACPI "companion" (ie. ACPI namespace node representing the host bridge itself). > That seems like an improvement to me, but it *is* different. Well, then we should make every ACPI device node corresponding to a PCI device be a parent of that device's struct pci_dev and so on for other bus types. It doesn't sound like an attractive idea. :-) Moreover, it is impossible, because those things generally already have parents (struct pci_dev objects have them at least). That said the idea to pass something meaningful in the parent argument of pci_create_root_bus() can be implemented if we create a "physical" device object corresponding to "device:00" (which is an ACPI namespace node) in your example. >From what I can tell, "device:00" always corresponds to the ACPI _SB scope (which is mandatory), so in principle we can create an abstract "physical" device object for it and call it something like "system_root". Then, if we use it as the parent of pci:00 (the host bridge), then we'll have /sys/devices/system_root/pci:00 /sys/devices/system_root/pci:00/:00:00.0 Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: prefer dev_( to dev_printk(KERN_
On Wed, Jan 2, 2013 at 6:06 PM, Joe Perches wrote:
> Add YA check to printk style.
>
> dev_ uses are functions and generate smaller
> object code than dev_printk(KERN_.
>
> Signed-off-by: Joe Perches
> ---
> scripts/checkpatch.pl | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4d2c7df..f50b32d 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2430,6 +2430,16 @@ sub process {
> "Prefer pr_warn(... to pr_warning(...\n" .
> $herecurr);
> }
>
> + if ($line =~ /\bdev_printk\s*\(\s*KERN_([A-Z]+)/) {
> + my $orig = $1;
> + my $level = lc($orig);
> + $level = "warn" if ($level eq "warning");
> + my $level2 = $level;
> + $level2 = "dbg" if ($level eq "debug");
> + WARN("PREFER_DEV_LEVEL",
> +"Prefer dev_$level2(... to
> dev_printk(KERN_$orig, ...\n" . $herecurr);
This suggests dev_dbg() instead of dev_printk(KERN_DEBUG), doesn't it?
Those aren't equivalent (dev_printk() always does the printk, but in
many cases dev_dbg() does not, depending on CONFIG_DEBUG,
CONFIG_DYNAMIC_DEBUG, etc.)
> + }
> +
> # function brace can't be on same line, except for #defines of do while,
> # or if closed on same line
> if (($line=~/$Type\s*$Ident\(.*\).*\s{/) and
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nfsd: Pass correct slot number to nfsd4_put_drc_mem()
On Mon, Dec 24, 2012 at 06:11:27PM +0800, ycn...@gmail.com wrote:
> From: Yanchuan Nian
>
> In alloc_session(), numslots is the correct slot number used by the session.
> But the slot number passed to nfsd4_put_drc_mem() is the one from nfs client.
Thanks, applying for 3.9.--b.
>
> Signed-off-by: Yanchuan Nian
> ---
> fs/nfsd/nfs4state.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index ac8ed96..29924a0 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -905,7 +905,7 @@ static struct nfsd4_session *alloc_session(struct
> nfsd4_channel_attrs *fchan,
>
> new = __alloc_session(slotsize, numslots);
> if (!new) {
> - nfsd4_put_drc_mem(slotsize, fchan->maxreqs);
> + nfsd4_put_drc_mem(slotsize, numslots);
> return NULL;
> }
> init_forechannel_attrs(&new->se_fchannel, fchan, numslots, slotsize,
> nn);
> --
> 1.7.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
