On Wed, Sep 10, 2014 at 04:24:16PM -0700, Hugh Dickins wrote: > On Wed, 10 Sep 2014, Prarit Bhargava wrote: > > > I see this when I attempt to login via ssh. I do not see it if I login on > > the serial console. .... > > > > According to Dave Chinner: > > > > "It's the shmem code that is broken - instantiating an inode while > > holding the mmap_sem inverts lock orders all over the place, > > especially in the security subsystem...." > > Interesting, thank you. But it seems a bit late to accuse shmem > of doing the wrong thing here: mmap -> shmem_zero_setup worked this > way in 2.4.0 (if not before) and has done ever since. > > Only now is a problem reported, so perhaps a change is needed rather > at the xfs end - unless Dave has a suggestion for how to change it > easily at the shmem end. > > Or is xfs not the one to change recently, but something else in the stack? XFS recently added directory inode specific lockdep class annotations. AFAIA, nobody else has done this so nobody else will have tripped over this issue. Effectively, lockdep is complaining that shmem is taking inode security locks in a different order to what it sees XFS taking directory locks and page faults in the readdir path. That is, VFS lock order is directory i_mutex/security lock on file creation, directory i_mutex/filldir/may_fault(mmap_sem) on readdir operations. Hence both the security lock and mmap_sem nest under i_mutex in real filesystems, but on shmem the security lock nests under mmap_sem because of inode instantiation. Now, lockdep is too naive to realise that these are completely different filesystems and so (probably) aren't in danger of deadlocks, but the fact is that having shmem instantiate an inode as a result of a page fault is -surprising- to say the least. I said that "It's the shmem code that is broken" bluntly because this has already been reported to the linux-mm list twice by me, and it's been ignored twice. it may be that what shmem is doing is OK, but the fact is that it is /very different/ to anyone else and is triggering lockdep reports against the normal behaviour on other filesystems. My point is that avoiding the lockdep report or fixing any other issue that it uncovers is not an XFS problem - shmem is doing the weird thing and we should not be working around shmem idiosyncracies in XFS or other filesystems.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>