On Fri, 2013-04-05 at 09:21 -0400, Rik van Riel wrote:
> On 04/05/2013 12:38 AM, Mike Galbraith wrote:
> > On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
>
> >> The ipc semaphore code has a nasty RCU locking tangle, with both
> >> find_alloc_undo and semtimedop taking the
On Fri, 2013-04-05 at 09:21 -0400, Rik van Riel wrote:
On 04/05/2013 12:38 AM, Mike Galbraith wrote:
On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
The ipc semaphore code has a nasty RCU locking tangle, with both
find_alloc_undo and semtimedop taking the rcu_read_lock(). The
On Fri, 2013-04-05 at 09:21 -0400, Rik van Riel wrote:
> On 04/05/2013 12:38 AM, Mike Galbraith wrote:
> > On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
>
> >> The ipc semaphore code has a nasty RCU locking tangle, with both
> >> find_alloc_undo and semtimedop taking the
On 04/05/2013 12:38 AM, Mike Galbraith wrote:
On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
The ipc semaphore code has a nasty RCU locking tangle, with both
find_alloc_undo and semtimedop taking the rcu_read_lock(). The
code can be cleaned up somewhat by only taking the rcu_read_lock
On 04/05/2013 12:38 AM, Mike Galbraith wrote:
On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
The ipc semaphore code has a nasty RCU locking tangle, with both
find_alloc_undo and semtimedop taking the rcu_read_lock(). The
code can be cleaned up somewhat by only taking the rcu_read_lock
On Fri, 2013-04-05 at 09:21 -0400, Rik van Riel wrote:
On 04/05/2013 12:38 AM, Mike Galbraith wrote:
On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
The ipc semaphore code has a nasty RCU locking tangle, with both
find_alloc_undo and semtimedop taking the rcu_read_lock(). The
On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
> On Tue, 26 Mar 2013 14:07:14 -0400
> Sasha Levin wrote:
>
> > > Not necessarily, we do release everything at the end of the function:
> > > out_unlock_free:
> > > sem_unlock(sma, locknum);
> >
> > Ow, there's a rcu_read_unlock()
On Tue, 2013-03-26 at 16:00 -0400, Rik van Riel wrote:
On Tue, 26 Mar 2013 14:07:14 -0400
Sasha Levin sasha.le...@oracle.com wrote:
Not necessarily, we do release everything at the end of the function:
out_unlock_free:
sem_unlock(sma, locknum);
Ow, there's a
On Sat, 2013-03-30 at 21:30 -0400, Rik van Riel wrote:
> On 03/30/2013 09:35 AM, Sasha Levin wrote:
>
> > I'm thinking that the solution is as simple as:
>
> Your patch is absolutely correct. All it needs now is your
> signed-off-by, so Andrew can merge it into -mm :)
>
> Reviewed-by: Rik van
On 03/30/2013 09:35 AM, Sasha Levin wrote:
I'm thinking that the solution is as simple as:
Your patch is absolutely correct. All it needs now is your
signed-off-by, so Andrew can merge it into -mm :)
Reviewed-by: Rik van Riel
diff --git a/ipc/sem.c b/ipc/sem.c
index 6e109ef..ac36671
On 03/28/2013 11:32 AM, Rik van Riel wrote:
> On Tue, 26 Mar 2013 13:33:07 -0400
> Sasha Levin wrote:
>
>> > [ 96.347341]
>> > [ 96.348085] [ BUG: lock held when returning to user space! ]
>> > [ 96.348834]
On 03/28/2013 11:32 AM, Rik van Riel wrote:
On Tue, 26 Mar 2013 13:33:07 -0400
Sasha Levin sasha.le...@oracle.com wrote:
[ 96.347341]
[ 96.348085] [ BUG: lock held when returning to user space! ]
[ 96.348834]
On 03/30/2013 09:35 AM, Sasha Levin wrote:
I'm thinking that the solution is as simple as:
Your patch is absolutely correct. All it needs now is your
signed-off-by, so Andrew can merge it into -mm :)
Reviewed-by: Rik van Riel r...@redhat.com
diff --git a/ipc/sem.c b/ipc/sem.c
index
On Sat, 2013-03-30 at 21:30 -0400, Rik van Riel wrote:
On 03/30/2013 09:35 AM, Sasha Levin wrote:
I'm thinking that the solution is as simple as:
Your patch is absolutely correct. All it needs now is your
signed-off-by, so Andrew can merge it into -mm :)
Reviewed-by: Rik van Riel
On 03/28/2013 09:00 PM, Michel Lespinasse wrote:
> On Thu, Mar 28, 2013 at 8:32 AM, Rik van Riel wrote:
>> The ipc semaphore code has a nasty RCU locking tangle, with both
>> find_alloc_undo and semtimedop taking the rcu_read_lock(). The
>> code can be cleaned up somewhat by only taking the
On Thu, Mar 28, 2013 at 8:32 AM, Rik van Riel wrote:
> The ipc semaphore code has a nasty RCU locking tangle, with both
> find_alloc_undo and semtimedop taking the rcu_read_lock(). The
> code can be cleaned up somewhat by only taking the rcu_read_lock
> once.
>
> The only caller of
On Thu, 2013-03-28 at 11:32 -0400, Rik van Riel wrote:
> On Tue, 26 Mar 2013 13:33:07 -0400
> Sasha Levin wrote:
>
> > [ 96.347341]
> > [ 96.348085] [ BUG: lock held when returning to user space! ]
> > [ 96.348834]
On Thu, 2013-03-28 at 11:32 -0400, Rik van Riel wrote:
On Tue, 26 Mar 2013 13:33:07 -0400
Sasha Levin sasha.le...@oracle.com wrote:
[ 96.347341]
[ 96.348085] [ BUG: lock held when returning to user space! ]
[ 96.348834]
On Thu, Mar 28, 2013 at 8:32 AM, Rik van Riel r...@surriel.com wrote:
The ipc semaphore code has a nasty RCU locking tangle, with both
find_alloc_undo and semtimedop taking the rcu_read_lock(). The
code can be cleaned up somewhat by only taking the rcu_read_lock
once.
The only caller of
On 03/28/2013 09:00 PM, Michel Lespinasse wrote:
On Thu, Mar 28, 2013 at 8:32 AM, Rik van Riel r...@surriel.com wrote:
The ipc semaphore code has a nasty RCU locking tangle, with both
find_alloc_undo and semtimedop taking the rcu_read_lock(). The
code can be cleaned up somewhat by only taking
20 matches
Mail list logo
