On Wed, Sep 3, 2014 at 5:58 PM,  <[email protected]> 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 <[email protected]> know about it.
>
>
> From 65b38851a17472d31fec9019fc3a55b0802dab88 Mon Sep 17 00:00:00 2001
> From: "Eric W. Biederman" <[email protected]>
> 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" <[email protected]>
>
> 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

[email protected]
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to