From: ebiederm@xmission.com (Eric W. Biederman)
To: Stanislav Kinsbursky <skinsbursky@parallels.com>
Cc: "Trond.Myklebust\@netapp.com" <Trond.Myklebust@netapp.com>,
"linux-nfs\@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Pavel Emelianov <xemul@parallels.com>,
"neilb\@suse.de" <neilb@suse.de>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
James Bottomley <jbottomley@parallels.com>,
"bfields\@fieldses.org" <bfields@fieldses.org>,
"davem\@davemloft.net" <davem@davemloft.net>,
"devel\@openvz.org" <devel@openvz.org>
Subject: Re: [PATCH 01/11] SYSCTL: export root and set handling routines
Date: Mon, 19 Dec 2011 08:37:19 -0800 [thread overview]
Message-ID: <m1pqfkecw0.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4EEF2C9A.8000403@parallels.com> (Stanislav Kinsbursky's message of "Mon, 19 Dec 2011 16:22:50 +0400")
Stanislav Kinsbursky <skinsbursky@parallels.com> writes:
>> In practice what this means is that register_net_sysctl_table should
>> work for any sysctl file anywhere under /proc/sys. I think
>> register_net_sysctl_table is the right solution for your problem. The
>> only possible caveat I can think of is you might hit Al's performance
>> optimizations and need to create a common empty directory first with
>> register_sysctl_paths.
>
> Sorry, but I forgot to mention one more important goal I would like to achieve:
> I want to manage sysctl's variables in context of mount owner, but not viewer one.
> IOW imagine, that we have one two network namespaces: "A" and "B". Both of them
> have it's own net sysctl's root. And we have per-net sysctl "/proc/sys/var".
> And for ns "A" variable was set to 0, and for "B" - to 1.
> And B's "/proc/sys/var" is accessible from "A" namespace
> ("/chroot_path/proc/sys/var" for example).
> With this configuration I want to read "1" from both namespaces:
> owner "B" (/proc/sys/var) and "A" ("/chroot_path/proc/sys/var").
> Looks like simple using of register_net_sysctl_table doesn't allow me this,
> because current net ns is used. And to achieve this goal I need my own sysctl
> set for SUNRPC like it was done for network namespaces.
Doing that independently of the rest of the sysctls is pretty horrible
and confusing to users. What I am planning might suit your needs and
if not we need to talk some more about how to get the vfs to do
something reasonable.
>> That said since I am in the process of rewriting things some of this
>> may change a little bit, but hopefully not in ways that immediately
>> effect the users of register_sysctl_table.
>>
>> Don't use register_net_sysctl_ro_table. I think what the implementors
>> actually wanted was register_net_sysctl_table(&init_net, ...) and didn't
>> know it.
>>
>> Don't put subdirectories in your sysctl tables. Use a ctl_path to
>> specify the entire directory where the files should show up. Generally
>> the code is easier to read in that form, and the code is simpler to deal
>> with if we don't have to worry about directories.
>>
>> Don't play with the sysctl roots. It is my intention to completely kill
>> them off and replace them by moving the per net sysctl tree under
>> /proc/<pid>/sys/. Leaving behind symlinks in /proc/sys/net and I guess
>> ultimately in /proc/sys/sunrpc/ and /proc/sys/fs/nfs... Which actually
>> seems to better describe your mental model.
>>
>
>
> I'm afraid, that this approach this not allow me to achieve the goal, mentioned
> above, because current->nsproxy->net_ns will be used during lookup.
> Or maybe I misunderstanding here?
What I hope to do is to stop using current, and to behave like
/proc/net. Aka a per process view under /proc/<pid>/sys that matches
the namespaces of the specified process.
The VFS really hates my use of current in the sysctl case, and I intend
to stop.
I need to run and catch my plane. It doesn't look like I will have
access to this email address for the next two weeks :(
Eric
next prev parent reply other threads:[~2011-12-19 16:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 11:44 [PATCH 00/11] SUNRPC: make sysctl per network namespcase context Stanislav Kinsbursky
2011-12-14 11:44 ` [PATCH 01/11] SYSCTL: export root and set handling routines Stanislav Kinsbursky
2011-12-17 22:25 ` Eric W. Biederman
2011-12-19 8:56 ` Stanislav Kinsbursky
2011-12-19 10:15 ` Eric W. Biederman
2011-12-19 12:22 ` Stanislav Kinsbursky
2011-12-19 16:37 ` Eric W. Biederman [this message]
2011-12-19 17:24 ` Stanislav Kinsbursky
2012-01-03 3:49 ` Eric W. Biederman
2012-01-10 10:38 ` Stanislav Kinsbursky
2012-01-10 22:39 ` Eric W. Biederman
2012-01-11 9:47 ` Stanislav Kinsbursky
2012-01-11 17:21 ` Eric W. Biederman
2012-01-11 18:02 ` Stanislav Kinsbursky
2012-01-11 19:36 ` Eric W. Biederman
2012-01-12 9:17 ` Stanislav Kinsbursky
2011-12-14 11:44 ` [PATCH 02/11] SUNRPC: use syctl path instead of dummy parent table Stanislav Kinsbursky
2011-12-14 11:45 ` [PATCH 03/11] SUNRPC: sysctl root for debug table introduced Stanislav Kinsbursky
2011-12-14 11:45 ` [PATCH 04/11] SUNRPC: per-net sysctl's set introduced Stanislav Kinsbursky
2011-12-14 11:45 ` [PATCH 05/11] SUNRPC: register debug sysctl table per network namespace Stanislav Kinsbursky
2011-12-14 11:45 ` [PATCH 06/11] SUNRPC: register xs_tunables " Stanislav Kinsbursky
2011-12-14 11:45 ` [PATCH 07/11] SUNRPC: xs tunables per network namespace introduced Stanislav Kinsbursky
2011-12-14 11:45 ` [PATCH 08/11] SUNRPC: use per-net xs tunables instead of static ones Stanislav Kinsbursky
2011-12-14 11:45 ` [PATCH 09/11] SUNRPC: remove xs_tcp_fin_timeout variable Stanislav Kinsbursky
2011-12-14 11:46 ` [PATCH 10/11] SUNRPC: allow debug flags modifications only from init_net Stanislav Kinsbursky
2011-12-14 11:46 ` [PATCH 11/11] SUNRPC: sysctl table for rpc_debug introduced Stanislav Kinsbursky
2012-02-07 11:44 ` [PATCH 00/11] SUNRPC: make sysctl per network namespcase context Stanislav Kinsbursky
2012-02-07 13:21 ` Myklebust, Trond
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=m1pqfkecw0.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=devel@openvz.org \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=skinsbursky@parallels.com \
--cc=xemul@parallels.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome