On Wed, Sep 3, 2014 at 5:58 PM, <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > This is a note to let you know that I've just added the patch titled > > NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes > > to the 3.16-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: > nfs-fix-proc-fs-nfsfs-servers-and-proc-fs-nfsfs-volumes.patch > and it can be found in the queue-3.16 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable@xxxxxxxxxxxxxxx> know about it. > > > From 65b38851a17472d31fec9019fc3a55b0802dab88 Mon Sep 17 00:00:00 2001 > From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > Date: Thu, 31 Jul 2014 04:35:20 -0700 > Subject: NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes > > From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > > commit 65b38851a17472d31fec9019fc3a55b0802dab88 upstream. > > The usage of pid_ns->child_reaper->nsproxy->net_ns in > nfs_server_list_open and nfs_client_list_open is not safe. > > /proc for a pid namespace can remain mounted after the all of the > process in that pid namespace have exited. There are also times > before the initial process in a pid namespace has started or after the > initial process in a pid namespace has exited where > pid_ns->child_reaper can be NULL or stale. Making the idiom > pid_ns->child_reaper->nsproxy a double whammy of problems. > > Luckily all that needs to happen is to move /proc/fs/nfsfs/servers and > /proc/fs/nfsfs/volumes under /proc/net to /proc/net/nfsfs/servers and > /proc/net/nfsfs/volumes and add a symlink from the original location, > and to use seq_open_net as it has been designed. > Can we please hold on this one. The upstream commit breaks mainline as it stands, causing Oopses. -- 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