From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Stephen Mell <sub.atomic.fusion@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] proc: move proc mount options out of pid_namespace
Date: Fri, 24 May 2013 18:04:47 +0800 [thread overview]
Message-ID: <519F3B3F.2070809@cn.fujitsu.com> (raw)
In-Reply-To: <1642748.MrLhTUgxmu@pegasus>
On 05/24/2013 05:35 PM, Stephen Mell wrote:
> On Friday, May 24, 2013 17:14:13 Gu Zheng wrote:
>
>> One fuzzy way in my mind, I'm not sure whether it's OK, but we can discuss it.
>> Split hide_pid, pid_gid, and proc_self from pid_namespace, and create struct proc_sb_info(maybe the name "proc_mount_info" is better).
>> And create a new list domain in the pid_namespace to contain the proc_sb_info instances. Each time we mount proc in a new directory only
>> create a new proc_sb_info instance, and added it to the list in pid_namespace.
>> But this leads to another problem, how to get the right proc_sb_info instance in proc permission checking routine, do you have any idea?
>> what do you think of this way?
>
> I understand now what you're getting at.
> However, I'd like to make the argument that it is desirable to have each proc mount, even those that reference the same namespace, have a different superblock. One option that I intend to add is the ability to specify which pid namespace proc is mounted for, rather than forcing the current one. If this were to be added, it wouldn't work to share superblocks, as that would prevent remounts of proc from switching which namespace that the refer to (or that is my understanding, which may be incorrect).
> Considering the small number of proc mounts that tend to be around anyway, perhaps this outweighs the drawbacks.
> Let me know what you think.
It doesn't matter, if we can not find a better way, the current one is best, go ahead!:)
Thanks,
Gu
>
>> Thanks,
>> Gu
>
> Thanks,
> Stephen
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2013-05-24 10:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 8:05 [PATCH] proc: move proc mount options out of pid_namespace Stephen Mell
2013-05-23 10:20 ` Gu Zheng
2013-05-23 23:32 ` Stephen Mell
2013-05-24 3:03 ` Gu Zheng
2013-05-24 4:29 ` Stephen Mell
2013-05-24 9:14 ` Gu Zheng
2013-05-24 9:35 ` Stephen Mell
2013-05-24 10:04 ` Gu Zheng [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-05-25 7:32 Stephen Mell
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=519F3B3F.2070809@cn.fujitsu.com \
--to=guz.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sub.atomic.fusion@gmail.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;
as well as URLs for NNTP newsgroup(s).