From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>,
Christoph Hellwig <hch@infradead.org>
Cc: Viro Alexander <viro@ZenIV.linux.org.uk>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Devel FS Linux <linux-fsdevel@vger.kernel.org>,
Torvalds Linus <torvalds@linux-foundation.org>,
Eric Biederman <ebiederm@xmission.com>
Subject: Re: [PATCH 00/11] [RFC] repair net namespace damage to rpc_pipefs
Date: Mon, 2 Dec 2013 18:24:43 +0400 [thread overview]
Message-ID: <529C982B.2030906@parallels.com> (raw)
In-Reply-To: <3C65EB4C-6592-44F8-B08D-E5A9EFD6C8C6@primarydata.com>
02.12.2013 17:44, Trond Myklebust пишет:
>
> On Dec 2, 2013, at 3:12, Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Sun, Dec 01, 2013 at 06:13:29PM +0000, Al Viro wrote:
>>> Making the series no-go in that form, obviously.
>>
>> Looking at the mess it made I'd almost be tempted to say a little leak
>> for a less used features is better than lots of pain for everyone..
>>
>> Looking at the mess it made I'm really upset.
>>
>>>> Given that the namespace kraken has infected various internal filesystem
>>>> and will get more soon I suspect this problem is or will become generic
>>>> and will need a proper solution anyway. Al, any good ideas how to deal
>>>> with this? Most straight forward way would be to add a counter of
>>>> user vfsmount to the superblock and methods when it goes to 1 and 0,
>>>> but that seems a bit ugly.
>>>
>>> Folks, please, _please_, let's formulate the lifecycle rules first; we
>>> already had way too much trouble from putting mechanism first only to
>>> run into questions like the above ("what happens if somebody tries to
>>> allocate a PID in pid_ns that is already scheduled for shutdown?").
>>> Remember the (recurring) fun with kobject-related lifetime issues?
>>> Or rpc_pipefs notifier ugliness, for that matter...
>>
>> I'll have to let the net namespace folks chime in for that, as far as
>> I'm concerned it's a featured better config'ed off. If they can't come
>> up with anything better the procfs hack above would be it.
>
> The lifetime of the kernel mount only needs to match that of the rpc_client, since each rpc_client is associated to a single net namespace, and each net namespace is in a 1-1 relationship with an rpc_pipefs super block.
>
> IOW: move the kernel mount/umount back to the rpc_client create/destroy methods and all should be well.
>
I'm sorry, guys, if I'm missing the point.
But there was the reason, why all this notifier infrastructure was introduced:
"RPC pipefs superblock should holds network namespace while active."
And that's why:
"RPC pipefs mount can't be performed in kernel context since new super block
will holds networks namespace reference and it's impossible to recognize, when
and how we have to release this mount point."
https://lkml.org/lkml/2011/10/17/123
Circumstances has changed and now all this can be fixed much simplier?
> Cheers
> Trond--
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best regards,
Stanislav Kinsbursky
WARNING: multiple messages have this Message-ID (diff)
From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>,
Christoph Hellwig <hch@infradead.org>
Cc: Viro Alexander <viro@ZenIV.linux.org.uk>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Devel FS Linux <linux-fsdevel@vger.kernel.org>,
Torvalds Linus <torvalds@linux-foundation.org>,
Eric Biederman <ebiederm@xmission.com>
Subject: Re: [PATCH 00/11] [RFC] repair net namespace damage to rpc_pipefs
Date: Mon, 2 Dec 2013 18:24:43 +0400 [thread overview]
Message-ID: <529C982B.2030906@parallels.com> (raw)
In-Reply-To: <3C65EB4C-6592-44F8-B08D-E5A9EFD6C8C6@primarydata.com>
02.12.2013 17:44, Trond Myklebust пишет:
>
> On Dec 2, 2013, at 3:12, Christoph Hellwig <hch@infradead.org> wrote:
>
>> On Sun, Dec 01, 2013 at 06:13:29PM +0000, Al Viro wrote:
>>> Making the series no-go in that form, obviously.
>>
>> Looking at the mess it made I'd almost be tempted to say a little leak
>> for a less used features is better than lots of pain for everyone..
>>
>> Looking at the mess it made I'm really upset.
>>
>>>> Given that the namespace kraken has infected various internal filesystem
>>>> and will get more soon I suspect this problem is or will become generic
>>>> and will need a proper solution anyway. Al, any good ideas how to deal
>>>> with this? Most straight forward way would be to add a counter of
>>>> user vfsmount to the superblock and methods when it goes to 1 and 0,
>>>> but that seems a bit ugly.
>>>
>>> Folks, please, _please_, let's formulate the lifecycle rules first; we
>>> already had way too much trouble from putting mechanism first only to
>>> run into questions like the above ("what happens if somebody tries to
>>> allocate a PID in pid_ns that is already scheduled for shutdown?").
>>> Remember the (recurring) fun with kobject-related lifetime issues?
>>> Or rpc_pipefs notifier ugliness, for that matter...
>>
>> I'll have to let the net namespace folks chime in for that, as far as
>> I'm concerned it's a featured better config'ed off. If they can't come
>> up with anything better the procfs hack above would be it.
>
> The lifetime of the kernel mount only needs to match that of the rpc_client, since each rpc_client is associated to a single net namespace, and each net namespace is in a 1-1 relationship with an rpc_pipefs super block.
>
> IOW: move the kernel mount/umount back to the rpc_client create/destroy methods and all should be well.
>
I'm sorry, guys, if I'm missing the point.
But there was the reason, why all this notifier infrastructure was introduced:
"RPC pipefs superblock should holds network namespace while active."
And that's why:
"RPC pipefs mount can't be performed in kernel context since new super block
will holds networks namespace reference and it's impossible to recognize, when
and how we have to release this mount point."
https://lkml.org/lkml/2011/10/17/123
Circumstances has changed and now all this can be fixed much simplier?
> Cheers
> Trond--
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-12-02 14:24 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-01 13:14 [PATCH 00/11] [RFC] repair net namespace damage to rpc_pipefs Christoph Hellwig
2013-12-01 13:14 ` [PATCH 01/11] sunrpc: allocate pipefs inodes using kmalloc Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 14:26 ` Jeff Layton
2013-12-01 14:26 ` Jeff Layton
2013-12-01 13:14 ` [PATCH 02/11] rpc_pipefs: always mount on net namespace initialization Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 15:24 ` Jeff Layton
2013-12-01 13:14 ` [PATCH 03/11] sunrpc: remove the rpc_clients_block notifier Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 15:25 ` Jeff Layton
2013-12-01 13:14 ` [PATCH 04/11] sunrpc: no need to have a lock or superblock for rpc_unlink Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 13:14 ` [PATCH 05/11] sunprc: add sensible pipe creation and removal helpers Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 13:14 ` [PATCH 06/11] sunrpc: clean up rpc_pipefs client dir creation Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 13:14 ` [PATCH 07/11] sunrpc: make rpc_mkdir_populate net-namespace aware Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 13:14 ` [PATCH 08/11] sunrpc: rpc_get_sb_net, die, die, die Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 13:14 ` [PATCH 09/11] nfs: convert idmapper to rpc_mkpipe_clnt Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 13:14 ` [PATCH 10/11] auth_gss: convert " Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 13:14 ` [PATCH 11/11] sunrpc: rpc_pipefs cleanup Christoph Hellwig
2013-12-01 13:14 ` Christoph Hellwig
2013-12-01 14:36 ` [PATCH 00/11] [RFC] repair net namespace damage to rpc_pipefs Jeff Layton
2013-12-01 14:36 ` Jeff Layton
2013-12-01 15:44 ` Jeff Layton
2013-12-01 15:44 ` Jeff Layton
2013-12-01 15:57 ` Jeff Layton
2013-12-01 18:13 ` Al Viro
2013-12-01 18:13 ` Al Viro
2013-12-02 8:12 ` Christoph Hellwig
2013-12-02 8:12 ` Christoph Hellwig
2013-12-02 13:44 ` Trond Myklebust
2013-12-02 14:24 ` Stanislav Kinsbursky [this message]
2013-12-02 14:24 ` Stanislav Kinsbursky
2013-12-02 15:36 ` Christoph Hellwig
2013-12-02 15:36 ` Christoph Hellwig
2013-12-02 15:58 ` Trond Myklebust
2013-12-02 15:58 ` Trond Myklebust
2013-12-03 7:24 ` Stanislav Kinsbursky
2013-12-03 7:24 ` Stanislav Kinsbursky
2013-12-02 15:34 ` Christoph Hellwig
2013-12-02 15:34 ` Christoph Hellwig
2013-12-02 16:00 ` Trond Myklebust
2013-12-02 16:00 ` Trond Myklebust
2013-12-02 16:27 ` Christoph Hellwig
2013-12-02 16:27 ` Christoph Hellwig
2013-12-02 16:46 ` Trond Myklebust
2013-12-02 16:46 ` Trond Myklebust
2013-12-02 16:33 ` Jeff Layton
2013-12-02 16:37 ` J. Bruce Fields
2013-12-02 16:45 ` Jeff Layton
2013-12-02 15:57 ` Al Viro
2013-12-02 15:57 ` Al Viro
2013-12-02 16:04 ` Trond Myklebust
2013-12-02 16:04 ` Trond Myklebust
2013-12-03 2:11 ` [RFC] alloc_pid() breakage Al Viro
2013-12-03 2:11 ` Al Viro
2013-12-02 7:23 ` [PATCH 00/11] [RFC] repair net namespace damage to rpc_pipefs Stanislav Kinsbursky
2013-12-02 7:23 ` Stanislav Kinsbursky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529C982B.2030906@parallels.com \
--to=skinsbursky@parallels.com \
--cc=ebiederm@xmission.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trond.myklebust@primarydata.com \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.