Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Rob
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Rol
The pcrypt_aead_init_tfm() function access the cpu_online_mask without
disabling CPU hotplug. And it looks like it can afford to sleep, so use
the get/put_online_cpus() APIs to protect against CPU hotplug.
Cc: Steffen Klassert
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.or
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Jen
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: "Da
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Fre
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from going
offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Cc: Joh
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-
Don't refer to stop_machine() in the CPU hotplug path, since we are going
to get rid of it. Also, move the comment referring to callback adoption
to the CPU_DEAD case, because that's where it happens now.
Signed-off-by: Srivatsa S. Bhat
---
kernel/rcutree.c |9 -
1 file changed, 4 i
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from
going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-
We need not use the raw_spin_lock_irqsave/restore primitives because
all CPU_DYING notifiers run with interrupts disabled. So just use
raw_spin_lock/unlock.
Signed-off-by: Srivatsa S. Bhat
---
kernel/sched/core.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() or local_irq_disable() to prevent CPUs from going
offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() to prevent CPUs from going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bha
Once stop_machine() is gone from the CPU offline path, we won't be able to
depend on preempt_disable() to prevent CPUs from going offline from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline,
while invoking from atomic context.
Signed-off-by: Srivatsa S. Bha
On 12/05/2012 06:10 AM, Andrew Morton wrote:
"static inline C functions would be preferred if possible. Feel free to
fix up the wrong crufty surrounding code as well ;-)"
Convert the macros in the CPU hotplug code to static inline C functions.
Signed-off-by: Srivatsa S. Bhat
---
include/linux
There are places where preempt_disable() or local_irq_disable() are used
to prevent any CPU from going offline during the critical section. Let us
call them as "atomic hotplug readers" ("atomic" because they run in atomic,
non-preemptible contexts).
Today, preempt_disable() or its equivalent works
CPU hotplug (which will be the first user of per-CPU rwlocks) has a special
requirement with respect to locking: the writer, after acquiring the per-CPU
rwlock for write, must be allowed to take the same lock for read, without
deadlocking and without getting complaints from lockdep. In comparison,
If interrupt handlers can also be readers, then one of the ways to make
per-CPU rwlocks safe, is to disable interrupts at the reader side before
trying to acquire the per-CPU rwlock and keep it disabled throughout the
duration of the read-side critical section.
The goal is to avoid cases such as:
Using global rwlocks as the backend for per-CPU rwlocks helps us avoid many
lock-ordering related problems (unlike per-cpu locks). However, global
rwlocks lead to unnecessary cache-line bouncing even when there are no
writers present, which can slow down the system needlessly.
Per-cpu counters can
Add the support for defining and initializing percpu-rwlocks at compile time
for those users who would like to use percpu-rwlocks really early in the boot
process (even before dynamic per-CPU allocations can begin).
Cc: David Howells
Signed-off-by: Srivatsa S. Bhat
---
include/linux/percpu-rwl
Per-CPU rwlocks ought to give better performance than global rwlocks.
That is where the "per-CPU" component comes in. So introduce the necessary
per-CPU variables that would be necessary at the reader and the writer sides,
and add the support for dynamically initializing per-CPU rwlocks.
These per-
A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
locks can also lead to too many deadlock possibilities which can make it very
hard/impossible to use. This is explained in the example below, which helps
justify the need for a different algorithm to implement flexible Pe
Hi,
This patchset removes CPU hotplug's dependence on stop_machine() from the CPU
offline path and provides an alternative (set of APIs) to preempt_disable() to
prevent CPUs from going offline, which can be invoked from atomic context.
The motivation behind the removal of stop_machine() is to avoi
Hi,
On Mon, Jan 21, 2013 at 7:23 PM, Steven Rostedt wrote:
> commit f96972f2dc "kernel/sys.c: call disable_nonboot_cpus() in
> kernel_restart()"
>
> added a call to disable_nonboot_cpus() on kernel_restart(), which tries
> to shutdown all the CPUs except the first one. The issue with the PA
> Sem
commit f96972f2dc "kernel/sys.c: call disable_nonboot_cpus() in
kernel_restart()"
added a call to disable_nonboot_cpus() on kernel_restart(), which tries
to shutdown all the CPUs except the first one. The issue with the PA
Semi, is that it does not support CPU hotplug.
When the call is made to __
On 01/21/2013 07:56:42 PM, Scott Wood wrote:
Previously we were setting an illegal configuration on mpc85xx
MPICs if CONFIG_IRQ_ALL_CPUS is enabled (which for some reason it is
in mpc85xx_smp_defconfig).
Signed-off-by: Scott Wood
Sigh, please ignore the repost of this and the CONFIG_IRQ_ALL_C
This will be used by the qemu-e500 platform, as the MPIC version (and
thus whether we have coreint) depends on how QEMU is configured.
Signed-off-by: Scott Wood
---
arch/powerpc/sysdev/mpic.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/p
While this should be harmless now that distribute_irqs
obeys MPIC_SINGLE_DEST_CPU, there's no reason to enable this
on mpc85xx/mpc86xx since MPIC_SINGLE_DEST_CPU will always be set.
Signed-off-by: Scott Wood
---
arch/powerpc/configs/85xx/ge_imp3a_defconfig |1 -
arch/powerpc/configs/86xx/g
The MPIC code will disable coreint if it detects an insufficient
MPIC version.
Signed-off-by: Scott Wood
---
arch/powerpc/platforms/85xx/qemu_e500.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c
b/arch/powerpc/platforms/85x
Previously we were setting an illegal configuration on mpc85xx
MPICs if CONFIG_IRQ_ALL_CPUS is enabled (which for some reason it is
in mpc85xx_smp_defconfig).
Signed-off-by: Scott Wood
---
arch/powerpc/sysdev/mpic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powe
Jiri Olsa [jo...@redhat.com] wrote:
| On Fri, Jan 18, 2013 at 05:30:52PM -0800, Sukadev Bhattiprolu wrote:
| > From 4d266e5040c33103f5d226b0d16b89f8ef79e3ad Mon Sep 17 00:00:00 2001
| > From: Sukadev Bhattiprolu
| > Date: Fri, 18 Jan 2013 11:14:28 -0800
| > Subject: [PATCH] perf: Fix compile warni
On Sat, Jan 19, 2013 at 08:59:18PM -0500, Paul Gortmaker wrote:
> On Thu, Jan 17, 2013 at 5:33 PM, Mark A. Greer wrote:
> > Hello.
> >
> > I want to make some fixups to the marvell hostbridge and
> > mpsc code and would like to test them on a PrPmc280/2800.
> > The problem is, I don't have one any
On 01/21/2013 03:41 PM, kishon wrote:
> Hi,
>
> On Monday 21 January 2013 06:48 PM, Roger Quadros wrote:
>> On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
>>> The OMAP glue has been modified to get PHY by phandle for dt boot.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I
>>> ---
>>> driv
On 01/21/2013 03:34 PM, kishon wrote:
> On Monday 21 January 2013 06:51 PM, Roger Quadros wrote:
>> On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
>>> Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
>>> device node phandle value. This function will return a pointer to
On Fri, Jan 18, 2013 at 05:30:52PM -0800, Sukadev Bhattiprolu wrote:
> From 4d266e5040c33103f5d226b0d16b89f8ef79e3ad Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Fri, 18 Jan 2013 11:14:28 -0800
> Subject: [PATCH] perf: Fix compile warnings in tests/attr.c
>
> Replace '%llu' in pri
Hi,
On Monday 21 January 2013 06:48 PM, Roger Quadros wrote:
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 inse
On Monday 21 January 2013 06:51 PM, Roger Quadros wrote:
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
device node phandle value. This function will return a pointer to
the phy on success, -EPROBE_DEFER if there is a
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
> Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
> device node phandle value. This function will return a pointer to
> the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
> but the phy has not be
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
> The OMAP glue has been modified to get PHY by phandle for dt boot.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/musb/omap2430.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/
From: Julia Lawall
Delete successive tests to the same location. The code tested the result
of a previous call, that itself was already tested. It is changed to test
the result of the most recent call.
A simplified version of the semantic match that finds this problem is as
follows: (http://co
41 matches
Mail list logo
