From: Sasha Levin <sasha.levin@oracle.com>
To: Rik van Riel <riel@surriel.com>
Cc: torvalds@linux-foundation.org, davidlohr.bueso@hp.com,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
hhuang@redhat.com, jason.low2@hp.com, walken@google.com,
lwoodman@redhat.com, chegu_vinod@hp.com,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo
Date: Sat, 30 Mar 2013 09:35:50 -0400 [thread overview]
Message-ID: <5156EA36.8050109@oracle.com> (raw)
In-Reply-To: <20130328113222.194bbfe8@cuia.bos.redhat.com>
On 03/28/2013 11:32 AM, Rik van Riel wrote:
> On Tue, 26 Mar 2013 13:33:07 -0400
> Sasha Levin <sasha.levin@oracle.com> wrote:
>
>> > [ 96.347341] ================================================
>> > [ 96.348085] [ BUG: lock held when returning to user space! ]
>> > [ 96.348834] 3.9.0-rc4-next-20130326-sasha-00011-gbcb2313 #318 Tainted: G W
>> > [ 96.360300] ------------------------------------------------
>> > [ 96.361084] trinity-child9/7583 is leaving the kernel with locks still held!
>> > [ 96.362019] 1 lock held by trinity-child9/7583:
>> > [ 96.362610] #0: (rcu_read_lock){.+.+..}, at: [<ffffffff8192eafb>] SYSC_semtimedop+0x1fb/0xec0
>> >
>> > It seems that we can leave semtimedop without releasing the rcu read lock.
> Sasha, this patch untangles the RCU locking with find_alloc_undo,
> and should fix the above issue. As a side benefit, this makes the
> code a little cleaner.
>
> Next up: implement locking in a way that does not trigger any
> lockdep warnings...
The following is mostly unrelated to this patch but close enough:
semctl_main() has a snippet that looks like this:
err = -EINVAL;
if(semnum < 0 || semnum >= nsems)
goto out_unlock;
sem_lock(sma, NULL, -1);
Which means we'll try unlocking the sma without trying to lock it first.
It makes lockdep unhappy:
[ 95.528492] =====================================
[ 95.529251] [ BUG: bad unlock balance detected! ]
[ 95.529897] 3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: G W
[ 95.530190] -------------------------------------
[ 95.530190] trinity-child14/9123 is trying to release lock (&(&new->lock)->rlock) at:
[ 95.530190] [<ffffffff8192f8e4>] semctl_main+0xe54/0xf00
[ 95.530190] but there are no more locks to release!
[ 95.530190]
[ 95.530190] other info that might help us debug this:
[ 95.530190] 1 lock held by trinity-child14/9123:
[ 95.530190] #0: (rcu_read_lock){.+.+..}, at: [<ffffffff8192ea90>] semctl_main+0x0/0xf00
[ 95.530190]
[ 95.530190] stack backtrace:
[ 95.530190] Pid: 9123, comm: trinity-child14 Tainted: G W 3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319
[ 95.530190] Call Trace:
[ 95.530190] [<ffffffff8192f8e4>] ? semctl_main+0xe54/0xf00
[ 95.530190] [<ffffffff8117b7e6>] print_unlock_imbalance_bug+0xf6/0x110
[ 95.530190] [<ffffffff8192f8e4>] ? semctl_main+0xe54/0xf00
[ 95.530190] [<ffffffff81180a35>] lock_release_non_nested+0xd5/0x320
[ 95.530190] [<ffffffff8122e3ab>] ? __do_fault+0x42b/0x530
[ 95.530190] [<ffffffff81179da2>] ? get_lock_stats+0x22/0x70
[ 95.530190] [<ffffffff81179e5e>] ? put_lock_stats.isra.14+0xe/0x40
[ 95.530190] [<ffffffff8192f8e4>] ? semctl_main+0xe54/0xf00
[ 95.530190] [<ffffffff81180f1e>] lock_release+0x29e/0x3b0
[ 95.530190] [<ffffffff819451f4>] ? security_ipc_permission+0x14/0x20
[ 95.530190] [<ffffffff83daf33e>] _raw_spin_unlock+0x1e/0x60
[ 95.530190] [<ffffffff8192f8e4>] semctl_main+0xe54/0xf00
[ 95.530190] [<ffffffff8192ea90>] ? SYSC_semtimedop+0xe30/0xe30
[ 95.530190] [<ffffffff8109d188>] ? kvm_clock_read+0x38/0x70
[ 95.530190] [<ffffffff8114feb5>] ? sched_clock_local+0x25/0xa0
[ 95.530190] [<ffffffff811500e8>] ? sched_clock_cpu+0xf8/0x110
[ 95.530190] [<ffffffff83db3814>] ? __do_page_fault+0x514/0x5e0
[ 95.530190] [<ffffffff81179da2>] ? get_lock_stats+0x22/0x70
[ 95.530190] [<ffffffff81179e5e>] ? put_lock_stats.isra.14+0xe/0x40
[ 95.530190] [<ffffffff83db3814>] ? __do_page_fault+0x514/0x5e0
[ 95.530190] [<ffffffff8113dc0e>] ? up_read+0x1e/0x40
[ 95.530190] [<ffffffff83db3814>] ? __do_page_fault+0x514/0x5e0
[ 95.530190] [<ffffffff811c6500>] ? rcu_eqs_exit_common+0x60/0x260
[ 95.530190] [<ffffffff81202b9d>] ? user_enter+0xfd/0x130
[ 95.530190] [<ffffffff81202c85>] ? user_exit+0xb5/0xe0
[ 95.530190] [<ffffffff8192faf9>] SyS_semctl+0x69/0x430
[ 95.530190] [<ffffffff81076ea0>] ? syscall_trace_enter+0x20/0x2e0
[ 95.530190] [<ffffffff83db7d18>] tracesys+0xe1/0xe6
I'm thinking that the solution is as simple as:
diff --git a/ipc/sem.c b/ipc/sem.c
index 6e109ef..ac36671 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1333,8 +1333,10 @@ static int semctl_main(struct ipc_namespace *ns, int semid, int semnum,
/* GETVAL, GETPID, GETNCTN, GETZCNT: fall-through */
}
err = -EINVAL;
- if(semnum < 0 || semnum >= nsems)
- goto out_unlock;
+ if(semnum < 0 || semnum >= nsems) {
+ rcu_read_unlock();
+ goto out_wakeup;
+ }
sem_lock(sma, NULL, -1);
curr = &sma->sem_base[semnum];
But I'm not 100% sure if I don't mess up anything else.
Thanks,
Sasha
next prev parent reply other threads:[~2013-03-30 13:37 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 19:55 ipc,sem: sysv semaphore scalability Rik van Riel
2013-03-20 19:55 ` [PATCH 1/7] ipc: remove bogus lock comment for ipc_checkid Rik van Riel
2013-03-20 19:55 ` [PATCH 2/7] ipc: introduce obtaining a lockless ipc object Rik van Riel
2013-03-20 19:55 ` [PATCH 3/7] ipc: introduce lockless pre_down ipcctl Rik van Riel
2013-03-20 19:55 ` [PATCH 4/7] ipc,sem: do not hold ipc lock more than necessary Rik van Riel
2013-03-20 19:55 ` [PATCH 5/7] ipc,sem: open code and rename sem_lock Rik van Riel
2013-03-22 1:14 ` Davidlohr Bueso
2013-03-20 19:55 ` [PATCH 6/7] ipc,sem: have only one list in struct sem_queue Rik van Riel
2013-03-22 1:14 ` Davidlohr Bueso
2013-03-20 19:55 ` [PATCH 7/7] ipc,sem: fine grained locking for semtimedop Rik van Riel
2013-03-22 1:14 ` Davidlohr Bueso
2013-03-22 23:01 ` Michel Lespinasse
2013-03-22 23:38 ` Rik van Riel
2013-03-22 23:42 ` [PATCH 7/7 part3] fix for sem_lock Rik van Riel
2013-03-20 20:49 ` ipc,sem: sysv semaphore scalability Linus Torvalds
2013-03-20 20:56 ` Linus Torvalds
2013-03-20 20:57 ` Davidlohr Bueso
2013-03-21 21:10 ` Andrew Morton
2013-03-21 21:47 ` Peter Hurley
2013-03-21 21:50 ` Peter Hurley
2013-03-21 22:01 ` Andrew Morton
2013-03-22 3:38 ` Rik van Riel
2013-03-26 19:28 ` Dave Jones
2013-03-26 19:43 ` Andrew Morton
2013-03-29 16:17 ` Dave Jones
2013-03-29 18:00 ` Linus Torvalds
2013-03-29 18:04 ` Dave Jones
2013-03-29 18:10 ` Linus Torvalds
2013-03-29 18:43 ` Linus Torvalds
2013-03-29 19:06 ` Dave Jones
2013-03-29 19:13 ` Linus Torvalds
2013-03-29 19:26 ` Linus Torvalds
2013-03-29 19:36 ` Peter Hurley
2013-04-02 16:08 ` Sasha Levin
2013-04-02 17:24 ` Linus Torvalds
2013-04-02 17:52 ` Linus Torvalds
2013-04-02 19:53 ` Sasha Levin
2013-04-02 20:00 ` Dave Jones
2013-03-29 19:33 ` Peter Hurley
2013-03-29 19:54 ` Linus Torvalds
2013-04-01 7:40 ` Stanislav Kinsbursky
2013-03-29 20:41 ` Linus Torvalds
2013-03-29 21:12 ` Linus Torvalds
2013-03-29 23:16 ` Linus Torvalds
2013-03-30 1:36 ` Emmanuel Benisty
2013-03-30 2:08 ` Davidlohr Bueso
2013-03-30 3:02 ` Emmanuel Benisty
2013-03-30 3:46 ` Linus Torvalds
2013-03-30 4:33 ` Emmanuel Benisty
2013-03-30 5:10 ` Linus Torvalds
2013-03-30 5:57 ` Emmanuel Benisty
2013-03-30 17:22 ` Linus Torvalds
2013-03-31 2:38 ` Emmanuel Benisty
2013-03-31 5:01 ` Davidlohr Bueso
2013-03-31 13:45 ` Rik van Riel
2013-03-31 17:10 ` Linus Torvalds
2013-03-31 17:02 ` Emmanuel Benisty
2013-03-30 2:09 ` Linus Torvalds
2013-03-30 2:55 ` Davidlohr Bueso
2013-03-29 19:01 ` Dave Jones
2013-05-03 15:03 ` Peter Hurley
2013-03-22 1:12 ` Davidlohr Bueso
2013-03-22 1:23 ` Linus Torvalds
2013-03-22 3:40 ` Rik van Riel
2013-03-22 7:30 ` Mike Galbraith
2013-03-22 11:04 ` Emmanuel Benisty
2013-03-22 15:37 ` Linus Torvalds
2013-03-23 3:19 ` Emmanuel Benisty
2013-03-23 19:45 ` Linus Torvalds
2013-03-24 13:46 ` Emmanuel Benisty
2013-03-24 17:10 ` Linus Torvalds
2013-03-25 13:47 ` Emmanuel Benisty
2013-03-25 14:00 ` Rik van Riel
2013-03-25 14:03 ` Rik van Riel
2013-03-25 15:20 ` Emmanuel Benisty
2013-03-25 15:53 ` Rik van Riel
2013-03-25 17:09 ` Emmanuel Benisty
2013-03-25 14:01 ` Rik van Riel
2013-03-25 14:21 ` Emmanuel Benisty
2013-03-26 17:59 ` Davidlohr Bueso
2013-03-26 18:14 ` Rik van Riel
2013-03-26 18:35 ` Andrew Morton
2013-04-16 23:30 ` Andrew Morton
2013-05-04 15:55 ` Jörn Engel
2013-05-04 18:12 ` Borislav Petkov
2013-05-06 14:47 ` Jörn Engel
2013-03-22 17:51 ` Davidlohr Bueso
2013-03-25 20:21 ` Sasha Levin
2013-03-25 20:38 ` [PATCH -mm -next] ipc,sem: fix lockdep false positive Rik van Riel
2013-03-25 21:42 ` Michel Lespinasse
2013-03-25 21:51 ` Michel Lespinasse
2013-03-25 21:56 ` Sasha Levin
2013-03-25 21:52 ` Sasha Levin
2013-03-26 13:19 ` Peter Zijlstra
2013-03-26 13:40 ` Michel Lespinasse
2013-03-26 14:27 ` Peter Zijlstra
2013-03-26 15:19 ` Rik van Riel
2013-03-27 8:40 ` Peter Zijlstra
2013-03-27 8:42 ` Peter Zijlstra
2013-03-27 11:22 ` Michel Lespinasse
2013-03-27 12:02 ` Peter Zijlstra
2013-03-27 20:00 ` Rik van Riel
2013-03-28 20:23 ` [PATCH v2 " Rik van Riel
2013-03-29 2:50 ` Michel Lespinasse
2013-03-29 9:57 ` Peter Zijlstra
2013-03-29 13:21 ` Michel Lespinasse
2013-03-29 12:07 ` Rik van Riel
2013-03-29 13:08 ` Michel Lespinasse
2013-03-29 13:24 ` Rik van Riel
2013-03-29 13:55 ` [PATCH v3 " Rik van Riel
2013-03-29 13:59 ` Michel Lespinasse
2013-03-26 14:25 ` [PATCH " Rik van Riel
2013-03-26 17:33 ` ipc,sem: sysv semaphore scalability Sasha Levin
2013-03-26 17:51 ` Davidlohr Bueso
2013-03-26 18:07 ` Sasha Levin
2013-03-26 18:17 ` Rik van Riel
2013-03-26 20:00 ` [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo Rik van Riel
2013-04-05 4:38 ` Mike Galbraith
2013-04-05 13:21 ` Rik van Riel
2013-04-05 16:26 ` Mike Galbraith
2013-04-16 12:37 ` Mike Galbraith
2013-03-26 17:55 ` ipc,sem: sysv semaphore scalability Paul E. McKenney
2013-03-28 15:32 ` [PATCH -mm -next] ipc,sem: untangle RCU locking with find_alloc_undo Rik van Riel
2013-03-28 21:05 ` Davidlohr Bueso
2013-03-29 1:00 ` Michel Lespinasse
2013-03-29 1:14 ` Sasha Levin
2013-03-30 13:35 ` Sasha Levin [this message]
2013-03-31 1:30 ` Rik van Riel
2013-03-31 4:09 ` Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5156EA36.8050109@oracle.com \
--to=sasha.levin@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=chegu_vinod@hp.com \
--cc=davidlohr.bueso@hp.com \
--cc=hhuang@redhat.com \
--cc=jason.low2@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=riel@surriel.com \
--cc=torvalds@linux-foundation.org \
--cc=walken@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).