From: Stephen Mell <sub.atomic.fusion@gmail.com>
To: Gu Zheng <guz.fnst@cn.fujitsu.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] proc: move proc mount options out of pid_namespace
Date: Fri, 24 May 2013 04:29:54 +0000 [thread overview]
Message-ID: <24900395.sMN6olMGRM@pegasus> (raw)
In-Reply-To: <519ED883.9060903@cn.fujitsu.com>
Gu,
On Friday, May 24, 2013 11:03:31 Gu Zheng wrote:
> Hi Stephen,
>
> On 05/24/2013 07:32 AM, Stephen Mell wrote:
>
> > On Thursday, May 23, 2013 18:20:57 Gu Zheng wrote:
> >
> >> Here it'll create a new proc sb instance which holds the same context as the old ones
> >> each time we mount proc though in the same PID namespace, won't it?
> > I believe so. But this is the point, right?
> Yes, but I think it's also the problem.
>
> >They won't be identical if different mount options are used, I don't think.
>
> If different mount options are used, we'll create different super block instance, and they have
> the same context, only the difference is each one holds different proc_sb_info.
> But I think what we really want is only one proc sb instance and create different proc_sb_info
> if different mount options are used.
Will having several different superblocks cause problems, or is it merely inefficient? I freely admit to not really knowing what I'm doing, and I thank you for your assistance.
How is this situation distinct from that of ramfs? It appears to have a superblock for each mount.
It would seem to me as though one cannot have different sb_infos with the same superblock, making storing the mount options in sb_info effectively the same as storing them in the superblock itself, for the purposes of this discussion. Where would the mount options be stored, if not in the superblock?
> >
> >> Here the pre-check seems needless.
> > Is that new with my patch, or has it always been needless?
>
> Yeah, it's always needless.
>
> Thanks,
> Gu
>
> >
> > Thanks,
> > Stephen
Thanks again,
Stephen
next prev parent reply other threads:[~2013-05-24 4:28 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 [this message]
2013-05-24 9:14 ` Gu Zheng
2013-05-24 9:35 ` Stephen Mell
2013-05-24 10:04 ` Gu Zheng
-- 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=24900395.sMN6olMGRM@pegasus \
--to=sub.atomic.fusion@gmail.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
/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.