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