Re: [PATCH 2/2] Replace pid_t in autofs with struct pid reference

[Ian Kent]

On Fri, 2007-03-16 at 05:32 -0600, Eric W. Biederman wrote:
> Ian Kent <raven@xxxxxxxxxx> writes:
> 
> > On Mon, 12 Mar 2007, sukadev@xxxxxxxxxx wrote:
> >
> >> 
> >> From: Sukadev Bhattiprolu <sukadev@xxxxxxxxxx>
> >> Subject: [PATCH 2/2] Replace pid_t in autofs with struct pid reference.
> >> 
> >> Make autofs container-friendly by caching struct pid reference rather
> >> than pid_t and using pid_nr() to retreive a task's pid_t.
> >> 
> >> ChangeLog:
> >> 	- Fix Eric Biederman's comments - Use find_get_pid() to hold a
> >> 	  reference to oz_pgrp and release while unmounting; separate out
> >> 	  changes to autofs and autofs4.
> >
> > What changes to autofs4?
> > Do you intend this change to be made for autofs4 also?
> > Perhaps you expected me to do them, in which case you probably should 
> > ask me to do the patch.
> 
> The review history goes something like this.
> - That's a big patch why are you touching autofs and autofs4 at the
>   same time?
> <split>
> - Hmm.  That change in the autofs4 patch looks fishy.
> <patch postponed until the issue was addressed>
> 
> autofs4 uses pids more extensively than autofs and so the change is
> correspondingly larger.
> 
> If you would like to look at what it would take to get autofs4 to only
> store values as struct pid * instead of storing pid_t that would be great.
> But for the most part I this is a massive global change that those of us
> pushing it are responsible for changing as fixing up as much of the code
> as we can, as is usual kernel practice.

How about you send over the autofs4 bit and I'll have a look (the autofs
patch looked fine). That would save me a bit of time and if there are
any changes needed I can send an updated patch for you guys to review. I
don't think autofs4 uses pids differently, in principle, than autofs so
it "should" be straight forward.

Ian


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/