Re: [PATCH 3.16.y-ckt 009/170] NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes

[Luis Henriques]

On Fri, Nov 14, 2014 at 06:36:25AM +0000, Ben Hutchings wrote:
> On Tue, 2014-11-11 at 11:06 +0000, Luis Henriques wrote:
> > 3.16.7-ckt1 -stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > 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.
> > 
> > Cc: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
> > Cc: Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx>
> > Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
> > Signed-off-by: Luis Henriques <luis.henriques@xxxxxxxxxxxxx>
> [...]
> 
> This needs a follow-up:
> 
> commit 21e81002f9788a3af591416b6dec60d7b67f2fb2
> Author: Cong Wang <xiyou.wangcong@xxxxxxxxx>
> Date:   Mon Sep 8 16:17:55 2014 -0700
> 
>     nfs: fix kernel warning when removing proc entry
> 

Thank you, Ben.  I missed that one.  Its now in the -review for this
release.

Cheers,
--
Luís

> Ben.
> 
> -- 
> Ben Hutchings
> Never put off till tomorrow what you can avoid all together.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/