Tried to boot next-20130607, got this during early boot. -0603 is OK, so
whatever did it is a recent patch. Not sure who's fault it is, as idr_preload()
has been there since February, apparently something in the SyS_semget()
path has been changed...
Looking at 'git blame', I see a bunch of patches from Davidlohr Bueso on 06/07
that hit ipc/util.c and friends.
[ 17.332871] BUG: sleeping function called from invalid context at lib/idr.c:424
[ 17.333013] in_atomic(): 0, irqs_disabled(): 0, pid: 231, name: systemd-cryptse
[ 17.333135] 2 locks held by systemd-cryptse/231:
[ 17.333226] #0: (&ids->rw_mutex){+++++.}, at: [<ffffffff811de265>] ipcget+0x58/0x162
[ 17.333650] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff811e020e>] rcu_read_lock+0x0/0x6c
[ 17.334103] CPU: 0 PID: 231 Comm: systemd-cryptse Not tainted 3.10.0-rc4-next-20130607 #79
[ 17.334227] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11 03/12/2013
[ 17.334347] 0000000000000000 ffff8801254e3e18 ffffffff815ebdd7 ffff88012545ecc0
[ 17.334706] ffff8801254e3e40 ffffffff8105b59b ffff8801262a1600 ffffffff81a3ee28
[ 17.335088] 00000000000000d0 ffff8801254e3e70 ffffffff812377ec ffff8801262a1618
[ 17.335445] Call Trace:
[ 17.335535] [<ffffffff815ebdd7>] dump_stack+0x4f/0x9a
[ 17.335633] [<ffffffff8105b59b>] __might_sleep+0x19e/0x1a5
[ 17.335730] [<ffffffff812377ec>] idr_preload+0xb7/0x15c
[ 17.335827] [<ffffffff811ddd0c>] ipc_addid+0x3a/0x168
[ 17.335924] [<ffffffff811e055f>] newary+0xa5/0x1b7
[ 17.336040] [<ffffffff811de349>] ipcget+0x13c/0x162
[ 17.336139] [<ffffffff811e19a8>] SyS_semget+0x5d/0x69
[ 17.336233] [<ffffffff811e04ba>] ? semctl_nolock.constprop.15+0x240/0x240
[ 17.336332] [<ffffffff811dfb4c>] ? sysvipc_sem_proc_show+0x9b/0x9b
[ 17.336430] [<ffffffff811df9f5>] ? __ticket_spin_is_locked+0x11/0x11
[ 17.336529] [<ffffffff815f9dd2>] system_call_fastpath+0x16/0x1b
[ 17.344508] bio: create slab <bio-1> at 1
On Tue, 2013-06-11 at 14:33 -0400, Valdis Kletnieks wrote:
> Tried to boot next-20130607, got this during early boot. -0603 is OK, so
> whatever did it is a recent patch. Not sure who's fault it is, as idr_preload()
> has been there since February, apparently something in the SyS_semget()
> path has been changed...
>
> Looking at 'git blame', I see a bunch of patches from Davidlohr Bueso on 06/07
> that hit ipc/util.c and friends.
Yeah, this is my fault. It was originally reported by Fengguang:
http://www.spinics.net/lists/kernel/msg1545633.html#.UbYI9qqdmV8
Sasha proposed a fix to use GFP_ATOMIC in idr_preload instead of
GFP_KERNEL:
http://lkml.org/lkml/2013/6/10/322
Thanks,
Davidlohr
On Tue, 11 Jun 2013 11:38:20 -0700, Davidlohr Bueso said:
> > Looking at 'git blame', I see a bunch of patches from Davidlohr Bueso on 06/07
> > that hit ipc/util.c and friends.
>
> Yeah, this is my fault. It was originally reported by Fengguang:
> http://www.spinics.net/lists/kernel/msg1545633.html#.UbYI9qqdmV8
>
> Sasha proposed a fix to use GFP_ATOMIC in idr_preload instead of
> GFP_KERNEL:
>
> http://lkml.org/lkml/2013/6/10/322
Confirming that Sasha's proposed fix eliminates the BUG in my kernel,
so if GFP_ATOMIC is acceptable otherwise, feel free to stick a Tested-By:
on it of you like.
On Wed, 2013-06-12 at 21:22 -0400, [email protected] wrote:
> On Tue, 11 Jun 2013 11:38:20 -0700, Davidlohr Bueso said:
>
> > > Looking at 'git blame', I see a bunch of patches from Davidlohr Bueso on 06/07
> > > that hit ipc/util.c and friends.
> >
> > Yeah, this is my fault. It was originally reported by Fengguang:
> > http://www.spinics.net/lists/kernel/msg1545633.html#.UbYI9qqdmV8
> >
> > Sasha proposed a fix to use GFP_ATOMIC in idr_preload instead of
> > GFP_KERNEL:
> >
> > http://lkml.org/lkml/2013/6/10/322
>
> Confirming that Sasha's proposed fix eliminates the BUG in my kernel,
> so if GFP_ATOMIC is acceptable otherwise, feel free to stick a Tested-By:
> on it of you like.
Actually, this is the fix we are going with:
https://lkml.org/lkml/2013/6/11/705
Thanks,
Davidlohr