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 ...
