Re: [PATCH] umount after bad chdir

[raven]

On Wed, 14 Apr 2004 viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:

> On Wed, Apr 14, 2004 at 11:13:13PM +0800, raven@xxxxxxxxxx wrote:
> > On Wed, 14 Apr 2004 raven@xxxxxxxxxx wrote:
> > 
> > > > Mind you, chdir() patch in -mm is broken in a lot of other ways - e.g.
> > > > it assumes that another thread sharing ->fs with us won't call chdir()
> > > > in the wrong moment...
> > > 
> > > Thanks for your interest Al.
> > > 
> > > I see your point (I think).
> > > 
> > > If I understand you correctly (please explain if I don't) I need to lock 
> > > the ->fs struct.
> > 
> > Mmm ... doesn't look much good in the light of Als comment.
> > 
> > Looks like it's not possible to take the lock for long enough even if I 
> > could.
> > 
> > Lets have some comments, criticisms or suggestions please.
> 
> Why do you need to assign pwd before revalidation?
> 

Good question.

I'm talking about lazy mounting in autofs version 4 (suprise, suprise).

I think this should be done in the call backs during the path_walk 
but I couldn't work out how. But see below...

The basic problem this is meant to solve is that I can't tell when a 
chdir or chroot is to be done from within the revalidate or lookup. To 
delay mounting until (or correctly trigger a mount at) the proper 
time I must know if the service request is a chdir or chroot, in which 
case an automount needs to be done. The chdir and chroot are the only 
problematic services that I'm aware of atm.

But looking further I see that a LOOKUP_DIRECTORY flag is used only for 
these two routines (excluding pivot_root) and when a trailing slash is 
present in the path. I think that the if this flag is present then the 
request will always want to look into the directory anyway, so if it's 
an autofs4 mount point it should be mounted then. If this is the case I 
can get this stuff into the fs module where it belongs.

I'll think about it some more and look around further before I do 
anything.

Thoughts?

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/