OpenVZ Forum


Home » Mailing lists » Devel » [PATCH 2/2] Replace pid_t in autofs with struct pid reference
Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference [message #17960 is a reply to message #17957] Thu, 22 March 2007 13:28 Go to previous messageGo to previous message
serue is currently offline  serue
Messages: 750
Registered: February 2006
Senior Member
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
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: Re: [PATCHSET] 2.6.20-lxc8
Next Topic: 2.6.20-lxc8 - compilation error
Goto Forum:
  


Current Time: Thu Aug 07 02:32:20 GMT 2025

Total time taken to generate the page: 1.27154 seconds