From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>, Ian Kent <raven@themaw.net>,
Cedric Le Goater <clg@fr.ibm.com>,
sukadev@us.ibm.com, Andrew Morton <akpm@osdl.org>,
Dave Hansen <haveblue@us.ibm.com>,
Herbert Poetzl <herbert@13thfloor.at>,
containers@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference
Date: Thu, 22 Mar 2007 08:28:53 -0500 [thread overview]
Message-ID: <20070322132853.GA22933@sergelap.austin.ibm.com> (raw)
In-Reply-To: <m1irctaidf.fsf@ebiederm.dsl.xmission.com>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> >
> > So is the pid used for anything other than debugging?
> >
> > In any case, here is a replacement patch which sends the pid number
> > in the pid_namespace of the process which did the autofs4 mount.
> >
> > Still not sure whether that is actually what makes sense...
> >
> > From: "Serge E. Hallyn" <serue@us.ibm.com>
> > Subject: [PATCH] autofs: prevent pid wraparound in waitqs
> >
> > Instead of storing pid numbers for waitqs, store references
> > to struct pids. Also store a reference to the mounter's pid
> > namespace in the autofs4 sb info so that pid numbers for
> > mount miss and expiry msgs can send the pid# in the mounter's
> > pidns.
>
> Hmm. Not quite what I would have expected but given that
> we are sending data over a pipe that sounds reasonable.
>
> If it wasn't a pipe we would really want to do this in
> the context of the process receiving the message, but since
> a pipe can receive a message, and then be passed to another
> process we clearly can't know the pid namespace of the
> process receiving the message.
>
> Therefore just caching the pid namespace either on pipe
> open or on mount makes sense. pipe open might be better.
Right, but the pipe is always opened on mount I think. (at
autofs4_fill_super)
> Serge we really need to introduce __pid_nr in a separate
> patch.
Agreed.
> And we really seem to be confusing Ian.
>
> Plus we have some pid namespace ref counting issues we need
> to handle carefully.
>
> Let's stop working on autofs4 for a bit, fix the pid namespace
> infrastructure so there is enough of it to handle autofs4 and
> then come back.
Agreed. I just wasn't comfortable stopping until I felt we knew how
autofs4 was going to be addressed. I think we know now, plus we've
verified another definite need for the __pid_nr(pidns, pid) helper.
> Either that or take autofs4 in two passes. Pass one we do what
> we can with the current infrastructure. Pass two after we fix up
> the infrastructure including introducing __pid_nr we come back
> and update autofs4 to handle multiple pid namespaces properly.
Nah, let's hold off, and I'll sit on a patch to send out once rest of
the infrastructure goes in.
-serge
prev parent reply other threads:[~2007-03-22 13:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 4:51 sukadev
2007-03-16 4:04 ` Ian Kent
2007-03-16 11:32 ` Eric W. Biederman
2007-03-16 14:31 ` Ian Kent
2007-03-16 14:44 ` Cedric Le Goater
2007-03-16 16:46 ` Ian Kent
2007-03-16 19:21 ` Eric W. Biederman
2007-03-19 20:08 ` Serge E. Hallyn
2007-03-19 20:40 ` Eric W. Biederman
2007-03-19 21:19 ` Serge E. Hallyn
2007-03-19 21:43 ` Eric W. Biederman
2007-03-20 20:15 ` Serge E. Hallyn
2007-03-20 20:45 ` Eric W. Biederman
2007-03-20 21:41 ` Serge E. Hallyn
2007-03-20 22:01 ` Eric W. Biederman
2007-03-21 20:58 ` Serge E. Hallyn
2007-03-22 2:28 ` Ian Kent
2007-03-22 14:33 ` Herbert Poetzl
2007-03-22 15:03 ` Ian Kent
2007-03-22 15:29 ` Eric W. Biederman
2007-03-22 15:22 ` Eric W. Biederman
2007-03-22 18:07 ` Serge E. Hallyn
2007-03-22 2:00 ` Ian Kent
2007-03-22 2:19 ` Serge E. Hallyn
2007-03-22 3:18 ` Ian Kent
2007-03-22 13:31 ` Serge E. Hallyn
2007-03-22 14:48 ` Ian Kent
2007-03-22 15:06 ` Ian Kent
2007-03-22 6:43 ` Eric W. Biederman
2007-03-22 13:28 ` Serge E. Hallyn [this message]
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=20070322132853.GA22933@sergelap.austin.ibm.com \
--to=serue@us.ibm.com \
--cc=akpm@osdl.org \
--cc=clg@fr.ibm.com \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=haveblue@us.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=raven@themaw.net \
--cc=sukadev@us.ibm.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
all inboxes | Powered by JetHome®