On Wed, 3 Oct 2012, Jiri Kosina wrote:
> How about the patch below? Pekka, Christoph, please?
Looks fine for -stable. For upstream there is going to be a move to
slab_common coming in this merge period. We would need a fix against -next
or Pekka's tree too.
--
To unsubscribe from this list:
On 10/03/2012 02:54 PM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
static void cpu_hotplug_begin(void)
{
cpu_hotplug.active_writer = current;
for (;;) {
mutex_lock(_hotplug.lock);
if
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
> >> static void cpu_hotplug_begin(void)
> >> {
> >> cpu_hotplug.active_writer = current;
> >>
> >> for (;;) {
> >> mutex_lock(_hotplug.lock);
> >> if (likely(!cpu_hotplug.refcount)) <
>
On 10/03/2012 01:49 PM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
>> On 10/03/2012 01:13 PM, Jiri Kosina wrote:
>>> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>>>
>>> CPU 0 CPU 1
>>> kmem_cache_destroy()
>>
>>
On 10/03/2012 11:38 AM, Srivatsa S. Bhat wrote:
> On 10/03/2012 09:20 AM, Srivatsa S. Bhat wrote:
>> On 10/03/2012 06:15 AM, Jiri Kosina wrote:
>>> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>>>
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
> On Tue, 2 Oct 2012, Paul E.
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
> On 10/03/2012 01:13 PM, Jiri Kosina wrote:
> > On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
> >
> > CPU 0 CPU 1
> > kmem_cache_destroy()
>
> What about the get_online_cpus() right here at
On 10/03/2012 01:13 PM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
> CPU 0 CPU 1
> kmem_cache_destroy()
What about the get_online_cpus() right here at CPU0 before
calling mutex_lock(slab_mutex)? How can the cpu_up()
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
> >>> CPU 0 CPU 1
> >>> kmem_cache_destroy()
> >>
> >> What about the get_online_cpus() right here at CPU0 before
> >> calling mutex_lock(slab_mutex)? How can the cpu_up() proceed
> >> on CPU1?? I still don't get it... :(
>
On 10/03/2012 09:20 AM, Srivatsa S. Bhat wrote:
> On 10/03/2012 06:15 AM, Jiri Kosina wrote:
>> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>>
>>> On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
> Indeed. Slab seems to be
On 10/03/2012 09:20 AM, Srivatsa S. Bhat wrote:
On 10/03/2012 06:15 AM, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
Indeed. Slab seems to be doing an rcu_barrier() in
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
CPU 0 CPU 1
kmem_cache_destroy()
What about the get_online_cpus() right here at CPU0 before
calling mutex_lock(slab_mutex)? How can the cpu_up() proceed
on CPU1?? I still don't get it... :(
On 10/03/2012 01:13 PM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
CPU 0 CPU 1
kmem_cache_destroy()
What about the get_online_cpus() right here at CPU0 before
calling mutex_lock(slab_mutex)? How can the cpu_up() proceed
on CPU1?? I still
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
On 10/03/2012 01:13 PM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
CPU 0 CPU 1
kmem_cache_destroy()
What about the get_online_cpus() right here at CPU0 before
calling
On 10/03/2012 11:38 AM, Srivatsa S. Bhat wrote:
On 10/03/2012 09:20 AM, Srivatsa S. Bhat wrote:
On 10/03/2012 06:15 AM, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
On 10/03/2012 01:49 PM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
On 10/03/2012 01:13 PM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
CPU 0 CPU 1
kmem_cache_destroy()
What about the get_online_cpus() right
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
static void cpu_hotplug_begin(void)
{
cpu_hotplug.active_writer = current;
for (;;) {
mutex_lock(cpu_hotplug.lock);
if (likely(!cpu_hotplug.refcount))
This one!
On 10/03/2012 02:54 PM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
static void cpu_hotplug_begin(void)
{
cpu_hotplug.active_writer = current;
for (;;) {
mutex_lock(cpu_hotplug.lock);
if (likely(!cpu_hotplug.refcount))
On Wed, 3 Oct 2012, Jiri Kosina wrote:
How about the patch below? Pekka, Christoph, please?
Looks fine for -stable. For upstream there is going to be a move to
slab_common coming in this merge period. We would need a fix against -next
or Pekka's tree too.
--
To unsubscribe from this list: send
On 10/03/2012 09:37 AM, Paul E. McKenney wrote:
> On Wed, Oct 03, 2012 at 09:29:01AM +0530, Srivatsa S. Bhat wrote:
>> On 10/03/2012 05:01 AM, Paul E. McKenney wrote:
>>> On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Jiri Kosina wrote:
On Wed, Oct 03, 2012 at 09:29:01AM +0530, Srivatsa S. Bhat wrote:
> On 10/03/2012 05:01 AM, Paul E. McKenney wrote:
> > On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
> >> On Tue, 2 Oct 2012, Jiri Kosina wrote:
> >>
> >> 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad
On 10/03/2012 09:14 AM, Paul E. McKenney wrote:
> On Wed, Oct 03, 2012 at 09:05:31AM +0530, Srivatsa S. Bhat wrote:
>> On 10/03/2012 03:47 AM, Jiri Kosina wrote:
>>> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>>>
I don't see how this circular locking dependency can occur.. If you are
On 10/03/2012 05:01 AM, Paul E. McKenney wrote:
> On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
>> On Tue, 2 Oct 2012, Jiri Kosina wrote:
>>
>> 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
>> commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
>> Author:
On 10/03/2012 06:15 AM, Jiri Kosina wrote:
> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>
>> On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
>>> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>>>
Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
notifier,
On Wed, Oct 03, 2012 at 09:05:31AM +0530, Srivatsa S. Bhat wrote:
> On 10/03/2012 03:47 AM, Jiri Kosina wrote:
> > On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
> >
> >> I don't see how this circular locking dependency can occur.. If you are
> >> using SLUB,
> >> kmem_cache_destroy() releases
On Wed, Oct 03, 2012 at 02:45:30AM +0200, Jiri Kosina wrote:
> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>
> > On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
> > > On Tue, 2 Oct 2012, Paul E. McKenney wrote:
> > >
> > > > Indeed. Slab seems to be doing an rcu_barrier() in a CPU
On 10/03/2012 03:47 AM, Jiri Kosina wrote:
> On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
>
>> I don't see how this circular locking dependency can occur.. If you are
>> using SLUB,
>> kmem_cache_destroy() releases slab_mutex before it calls rcu_barrier(). If
>> you are
>> using SLAB,
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
> On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
> > On Tue, 2 Oct 2012, Paul E. McKenney wrote:
> >
> > > Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
> > > notifier, which doesn't sit so well with rcu_barrier()
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
> On Tue, 2 Oct 2012, Paul E. McKenney wrote:
>
> > Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
> > notifier, which doesn't sit so well with rcu_barrier() trying to exclude
> > CPU hotplug events. I could go
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
> Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
> notifier, which doesn't sit so well with rcu_barrier() trying to exclude
> CPU hotplug events. I could go back to the old approach, but it is
> significantly more complex. I
On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
> On Tue, 2 Oct 2012, Jiri Kosina wrote:
>
> > > > > 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
> > > > > commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
> > > > > Author: Paul E. McKenney
> > > > > Date: Thu
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
> I don't see how this circular locking dependency can occur.. If you are using
> SLUB,
> kmem_cache_destroy() releases slab_mutex before it calls rcu_barrier(). If
> you are
> using SLAB, kmem_cache_destroy() wraps its whole operation inside
>
On Tue, 2 Oct 2012, Jiri Kosina wrote:
> > > > 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
> > > > commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
> > > > Author: Paul E. McKenney
> > > > Date: Thu Aug 2 17:43:50 2012 -0700
> > > >
> > > > rcu: Remove _rcu_barrier()
On Tue, 2 Oct 2012, Jiri Kosina wrote:
> > > 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
> > > commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
> > > Author: Paul E. McKenney
> > > Date: Thu Aug 2 17:43:50 2012 -0700
> > >
> > > rcu: Remove _rcu_barrier() dependency on
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
> > 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
> > commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
> > Author: Paul E. McKenney
> > Date: Thu Aug 2 17:43:50 2012 -0700
> >
> > rcu: Remove _rcu_barrier() dependency on
On 10/02/2012 09:44 PM, Jiri Kosina wrote:
> Hi,
>
> this commit:
>
> ==
> 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
> commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
> Author: Paul E. McKenney
> Date: Thu Aug 2 17:43:50 2012 -0700
>
> rcu: Remove _rcu_barrier()
On Tue, Oct 02, 2012 at 06:14:08PM +0200, Jiri Kosina wrote:
> Hi,
>
> this commit:
>
> ==
> 1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
> commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
> Author: Paul E. McKenney
> Date: Thu Aug 2 17:43:50 2012 -0700
>
> rcu: Remove
Hi,
this commit:
==
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney
Date: Thu Aug 2 17:43:50 2012 -0700
rcu: Remove _rcu_barrier() dependency on __stop_machine()
Currently, _rcu_barrier()
Hi,
this commit:
==
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney paul.mcken...@linaro.org
Date: Thu Aug 2 17:43:50 2012 -0700
rcu: Remove _rcu_barrier() dependency on __stop_machine()
On Tue, Oct 02, 2012 at 06:14:08PM +0200, Jiri Kosina wrote:
Hi,
this commit:
==
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney paul.mcken...@linaro.org
Date: Thu Aug 2 17:43:50 2012 -0700
On 10/02/2012 09:44 PM, Jiri Kosina wrote:
Hi,
this commit:
==
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney paul.mcken...@linaro.org
Date: Thu Aug 2 17:43:50 2012 -0700
rcu: Remove
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney paul.mcken...@linaro.org
Date: Thu Aug 2 17:43:50 2012 -0700
rcu: Remove _rcu_barrier()
On Tue, 2 Oct 2012, Jiri Kosina wrote:
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney paul.mcken...@linaro.org
Date: Thu Aug 2 17:43:50 2012 -0700
rcu: Remove _rcu_barrier()
On Tue, 2 Oct 2012, Jiri Kosina wrote:
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney paul.mcken...@linaro.org
Date: Thu Aug 2 17:43:50 2012 -0700
rcu: Remove _rcu_barrier()
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
I don't see how this circular locking dependency can occur.. If you are using
SLUB,
kmem_cache_destroy() releases slab_mutex before it calls rcu_barrier(). If
you are
using SLAB, kmem_cache_destroy() wraps its whole operation inside
On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Jiri Kosina wrote:
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney paul.mcken...@linaro.org
Date: Thu
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
notifier, which doesn't sit so well with rcu_barrier() trying to exclude
CPU hotplug events. I could go back to the old approach, but it is
significantly more complex. I cannot
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
notifier, which doesn't sit so well with rcu_barrier() trying to exclude
CPU hotplug events. I could go back to the
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
notifier, which doesn't sit so well with rcu_barrier() trying to
On 10/03/2012 03:47 AM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
I don't see how this circular locking dependency can occur.. If you are
using SLUB,
kmem_cache_destroy() releases slab_mutex before it calls rcu_barrier(). If
you are
using SLAB, kmem_cache_destroy()
On Wed, Oct 03, 2012 at 02:45:30AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
On Wed, Oct 03, 2012 at 09:05:31AM +0530, Srivatsa S. Bhat wrote:
On 10/03/2012 03:47 AM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
I don't see how this circular locking dependency can occur.. If you are
using SLUB,
kmem_cache_destroy() releases slab_mutex before
On 10/03/2012 06:15 AM, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
On Wed, Oct 03, 2012 at 01:48:21AM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Paul E. McKenney wrote:
Indeed. Slab seems to be doing an rcu_barrier() in a CPU hotplug
notifier, which doesn't sit so
On 10/03/2012 05:01 AM, Paul E. McKenney wrote:
On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Jiri Kosina wrote:
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit 1331e7a1bbe1f11b19c4327ba0853bee2a606543
Author: Paul E. McKenney
On 10/03/2012 09:14 AM, Paul E. McKenney wrote:
On Wed, Oct 03, 2012 at 09:05:31AM +0530, Srivatsa S. Bhat wrote:
On 10/03/2012 03:47 AM, Jiri Kosina wrote:
On Wed, 3 Oct 2012, Srivatsa S. Bhat wrote:
I don't see how this circular locking dependency can occur.. If you are
using SLUB,
On Wed, Oct 03, 2012 at 09:29:01AM +0530, Srivatsa S. Bhat wrote:
On 10/03/2012 05:01 AM, Paul E. McKenney wrote:
On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Jiri Kosina wrote:
1331e7a1bbe1f11b19c4327ba0853bee2a606543 is the first bad commit
commit
On 10/03/2012 09:37 AM, Paul E. McKenney wrote:
On Wed, Oct 03, 2012 at 09:29:01AM +0530, Srivatsa S. Bhat wrote:
On 10/03/2012 05:01 AM, Paul E. McKenney wrote:
On Tue, Oct 02, 2012 at 11:58:36PM +0200, Jiri Kosina wrote:
On Tue, 2 Oct 2012, Jiri Kosina wrote:
56 matches
Mail list logo
