On Tue, Mar 03, 2015 at 12:25:42PM -0500, Trond Myklebust wrote: > On Tue, Mar 3, 2015 at 11:41 AM, Bruno Prémont > <bonbons@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, 03 March 2015 Luis Henriques <luis.henriques@xxxxxxxxxxxxx> wrote: > >> On Sat, Feb 28, 2015 at 03:06:04PM -0800, Greg Kroah-Hartman wrote: > >> > > >> > This is a note to let you know that I've just added the patch titled > >> > > >> > SUNRPC: NULL utsname dereference on NFS umount during namespace cleanup > >> > > >> > to the 3.14-stable tree which can be found at: > >> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > >> > > >> > The filename of the patch is: > >> > sunrpc-null-utsname-dereference-on-nfs-umount-during-namespace-cleanup.patch > >> > and it can be found in the queue-3.14 subdirectory. > >> > > >> > If you, or anyone else, feels it should not be added to the stable tree, > >> > please let <stable@xxxxxxxxxxxxxxx> know about it. > >> > > >> > >> Maybe this is actually applicable to the 3.14 kernel, but it was > >> tagged for stable 3.18. Trond? Bruno? > > > > I've first hit the bug on 3.18 so I can't tell if it can be triggered > > with older releases. > > > > As I could pin-point the cause of crash and a possible fix/work-around I > > did not bisect to find out what made the NULL-pointer dereference possible. > > > > Guess is that a change in ordering of namespace cleanup process made the > > issue surface. > > > > On the other hand, to be confirmed by Trond, the use of utsname may still > > cause some issues due to hostname changes in some namespaces other than > > the one which initially mounted the share. The issues here would rather be > > at a higher level between nfs client and server (name used being different > > from expected name). > > > > I suspect that the main trigger is the commit 9ea459e110df ("delayed > mntput()"), since that divorces the mount cleanup from the umount > process context, but I have not tested that theory. > > Since we haven't heard of any earlier instances of the Oops than in > 3.18, then I suggest that we do not apply this patch to earlier > kernels (although it certainly should not harm those kernels) for now. > We can always change that decision later, should it prove wrong. > Awesome, thank you for all the feedback. I won't be queuing it for the 3.16 kernel then ;) Cheers, -- Luís > Cheers > Trond > -- > Trond Myklebust > Linux NFS client maintainer, PrimaryData > trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html