public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: 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 00:43:08 -0600	[thread overview]
Message-ID: <m1irctaidf.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20070322021931.GA11485@sergelap.austin.ibm.com> (Serge E. Hallyn's message of "Wed, 21 Mar 2007 21:19:31 -0500")

"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.

Serge we really need to introduce __pid_nr in a separate
patch.   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.

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.

Eric

  parent reply	other threads:[~2007-03-22  6:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-13  4:51 [PATCH 2/2] Replace pid_t in autofs with struct pid reference 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 [this message]
2007-03-22 13:28                               ` Serge E. Hallyn

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=m1irctaidf.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@osdl.org \
    --cc=clg@fr.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=serue@us.ibm.com \
    --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