Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1471884 > unrolled thread
| Started by | Takashi Iwai <tiwai@suse.de> |
|---|---|
| First post | 2016-08-29 16:40 +0200 |
| Last post | 2016-08-30 04:00 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" Takashi Iwai <tiwai@suse.de> - 2016-08-29 16:40 +0200
Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" Al Viro <viro@ZenIV.linux.org.uk> - 2016-08-29 17:20 +0200
Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" Ian Kent <raven@themaw.net> - 2016-08-30 03:40 +0200
Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" Ian Kent <raven@themaw.net> - 2016-08-30 04:00 +0200
| From | Takashi Iwai <tiwai@suse.de> |
|---|---|
| Date | 2016-08-29 16:40 +0200 |
| Subject | 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" |
| Message-ID | <sbvTb-8um-19@gated-at.bofh.it> |
Hi,
I noticed that a freshly booted 4.8-rc4 kernel gives the following
kernel messages a few times:
BUG: sleeping function called from invalid context at fs/dcache.c:757
in_atomic(): 1, irqs_disabled(): 0, pid: 8431, name: automount
1 lock held by automount/8431:
#0: (&(&sbi->fs_lock)->rlock){+.+...}, at: [<ffffffff81345736>] autofs4_expire_indirect+0x136/0x2d0
CPU: 4 PID: 8431 Comm: automount Not tainted 4.8.0-rc4-test2+ #210
Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013
0000000000000000 ffff8801843efc30 ffffffff813bbdd3 ffff88019e6500c0
ffffffff81a330b6 ffff8801843efc58 ffffffff810a3052 ffffffff81a330b6
00000000000002f5 0000000000000000 ffff8801843efc80 ffffffff810a3149
Call Trace:
[<ffffffff813bbdd3>] dump_stack+0x86/0xc3
[<ffffffff810a3052>] ___might_sleep+0x142/0x1f0
[<ffffffff810a3149>] __might_sleep+0x49/0x80
[<ffffffff81260b17>] ? dput+0x37/0x400
[<ffffffff81260b26>] dput+0x46/0x400
[<ffffffff8126c96d>] ? lookup_mnt+0x14d/0x1d0
[<ffffffff8124ff54>] ? follow_down_one+0x14/0x60
[<ffffffff8124ff67>] follow_down_one+0x27/0x60
[<ffffffff81344da2>] autofs4_mount_busy+0x32/0x110
[<ffffffff81345081>] should_expire+0x51/0x3d0
[<ffffffff81345790>] autofs4_expire_indirect+0x190/0x2d0
[<ffffffff81345fa0>] ? autofs_dev_ioctl_askumount+0x30/0x30
[<ffffffff81345bb4>] autofs4_do_expire_multi+0x94/0xb0
[<ffffffff81345fa0>] ? autofs_dev_ioctl_askumount+0x30/0x30
[<ffffffff81345fbf>] autofs_dev_ioctl_expire+0x1f/0x30
[<ffffffff81346679>] _autofs_dev_ioctl+0x2b9/0x350
[<ffffffff81346723>] autofs_dev_ioctl+0x13/0x20
[<ffffffff8125af54>] do_vfs_ioctl+0x94/0x690
[<ffffffff8126820d>] ? __fget+0x10d/0x200
[<ffffffff81268105>] ? __fget+0x5/0x200
[<ffffffff8125b5c9>] SyS_ioctl+0x79/0x90
[<ffffffff8170ef00>] entry_SYSCALL_64_fastpath+0x23/0xc1
I don't remember of a similar stack trace in the past, so if any, it
can be a regression in 4.8 kernel. But I cannot say it in 100%, as
this looks spontaneous, nor I would be able to reproduce it at the
next boot...
thanks,
Takashi
[toc] | [next] | [standalone]
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Date | 2016-08-29 17:20 +0200 |
| Subject | Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" |
| Message-ID | <sbwvT-v8-13@gated-at.bofh.it> |
| In reply to | #1471884 |
On Mon, Aug 29, 2016 at 04:35:46PM +0200, Takashi Iwai wrote: > [<ffffffff81260b26>] dput+0x46/0x400 ... which should not be called in atomic contexts > [<ffffffff8124ff67>] follow_down_one+0x27/0x60 ... and neither should this > [<ffffffff81344da2>] autofs4_mount_busy+0x32/0x110 ... nor that (for fsck sake, there's full-blown path_put() in it!) > [<ffffffff81345081>] should_expire+0x51/0x3d0 ... so that would better not be called in atomic either (incidentally, it also calls dput() directly) > [<ffffffff81345790>] autofs4_expire_indirect+0x190/0x2d0 ... while here it is called under sbi->fs_lock. > I don't remember of a similar stack trace in the past, so if any, it > can be a regression in 4.8 kernel. But I cannot say it in 100%, as > this looks spontaneous, nor I would be able to reproduce it at the > next boot... It's old; the race is narrow, but it's been there for quite a while, by the look of it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Kent <raven@themaw.net> |
|---|---|
| Date | 2016-08-30 03:40 +0200 |
| Subject | Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" |
| Message-ID | <sbGbT-6xL-1@gated-at.bofh.it> |
| In reply to | #1471913 |
On Mon, 2016-08-29 at 16:18 +0100, Al Viro wrote: > On Mon, Aug 29, 2016 at 04:35:46PM +0200, Takashi Iwai wrote: > > > [<ffffffff81260b26>] dput+0x46/0x400 > ... which should not be called in atomic contexts > > [<ffffffff8124ff67>] follow_down_one+0x27/0x60 > ... and neither should this > > [<ffffffff81344da2>] autofs4_mount_busy+0x32/0x110 > ... nor that (for fsck sake, there's full-blown path_put() in it!) > > [<ffffffff81345081>] should_expire+0x51/0x3d0 > ... so that would better not be called in atomic either (incidentally, > it also calls dput() directly) > > [<ffffffff81345790>] autofs4_expire_indirect+0x190/0x2d0 > ... while here it is called under sbi->fs_lock. > > > I don't remember of a similar stack trace in the past, so if any, it > > can be a regression in 4.8 kernel. But I cannot say it in 100%, as > > this looks spontaneous, nor I would be able to reproduce it at the > > next boot... > > It's old; the race is narrow, but it's been there for quite a while, by > the look of it. Right, I missed that when the rcu-walk concurrency changes went in, mmm ....
[toc] | [prev] | [next] | [standalone]
| From | Ian Kent <raven@themaw.net> |
|---|---|
| Date | 2016-08-30 04:00 +0200 |
| Subject | Re: 4.8-rc4 spews "BUG: sleeping function called from invalid context at fs/dcache.c:757" |
| Message-ID | <sbGvf-6E9-1@gated-at.bofh.it> |
| In reply to | #1472192 |
On Tue, 2016-08-30 at 09:37 +0800, Ian Kent wrote: > On Mon, 2016-08-29 at 16:18 +0100, Al Viro wrote: > > On Mon, Aug 29, 2016 at 04:35:46PM +0200, Takashi Iwai wrote: > > > > > [<ffffffff81260b26>] dput+0x46/0x400 > > ... which should not be called in atomic contexts > > > [<ffffffff8124ff67>] follow_down_one+0x27/0x60 > > ... and neither should this > > > [<ffffffff81344da2>] autofs4_mount_busy+0x32/0x110 > > ... nor that (for fsck sake, there's full-blown path_put() in it!) > > > [<ffffffff81345081>] should_expire+0x51/0x3d0 > > ... so that would better not be called in atomic either (incidentally, > > it also calls dput() directly) > > > [<ffffffff81345790>] autofs4_expire_indirect+0x190/0x2d0 > > ... while here it is called under sbi->fs_lock. > > > > > I don't remember of a similar stack trace in the past, so if any, it > > > can be a regression in 4.8 kernel. But I cannot say it in 100%, as > > > this looks spontaneous, nor I would be able to reproduce it at the > > > next boot... > > > > It's old; the race is narrow, but it's been there for quite a while, by > > the look of it. > > Right, I missed that when the rcu-walk concurrency changes went in, mmm .... Umm ... no, the problem has been there much longer than that ...
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web