Re: autofs4 looks up wrong path element when ghosting is enabled

[Ian Kent]

On Mon, 26 Sep 2005, Jeff Moyer wrote:

> ==> Regarding Re: autofs4 looks up wrong path element when ghosting is enabled; Ian Kent <raven@xxxxxxxxxx> adds:
> 
> raven> On Sat, 24 Sep 2005, Jeff Moyer wrote:
> >> >> >> >> >> Ian, I'm not really sure how we can address this issue
> >> without VFS >> >> changes.  Any ideas?
> >> >> >> 
> >> >> 
> raven> I'm aware of this problem.  I'm not sure how to deal with it yet.
> raven> The case above is probably not that difficult to solve but if the
> raven> last component is a directory it's hard to work out it's a problem.
> >> >> Ugh.  If you're thinking what I think you're thinking, that's an ugly
> >> >> hack.
> >> 
> raven> Don't think so.
> >>
> raven> I've been seeing this for a while. I wasn't quite sure of the source
> raven> but, for some reason your report has cleared that up.
> >>
> raven> The problem is not so much the success returned on the failed mount
> raven> (revalidate). It's the return from the following lookup. This is a
> raven> lookup in a non-root directory. I replaced the non-root lookup with
> raven> the root lookup a while ago and I think this is an unexpected side
> raven> affect of that. Becuase of other changes that lead to that decision
> raven> I think that it should be now be OK to put back the null function
> raven> (always return a negative dentry) that was there before I started
> raven> working on the browable maps feature.
> >>
> raven> I'll change the module I use here and test it out for a while.  If
> raven> you have time I could make a patch for the 2.4 code and send it over
> raven> so that you could test it out a bit as well.
> >> Just send along the 2.6 patch, since I have to deal with that, too.
> >> I'll go through the trouble of backporting it.
> 
> raven> I'm in the middle of working on lazy multi-mounts atm so I'm not in
> raven> a good position to test. It's a little tricky so I don't want to
> raven> forget where I'm at by getting side tracked.
> 
> raven> But here's the patch that I will apply to my v5 tree for the initial
> raven> testing. Hopefully you will be able to give it a run in a standard
> raven> setup.
> 
> I put together a different patch, but I want to get your input on the
> approach before I post it.  It requires both user-space and kernel-space
> changes.
> 
> Basically, you identify that a given automount tree is a direct map tree.
> This information is passed along to the kernel (I did this via a mount
> option), and recorded (in the super block info).  Then, when a directory
> lookup occurs, if we are in a direct map tree, and ghosting is enabled,
> then we pass the lookup on to the real lookup code.
> 
> I'm not sold on the approach, as I haven't thought through all of the
> implications.  Care to comment?
> 

Based on your description I'm not sure that this is the simplest approach.

The fundamental problem here is, I think, an incorrect return code from 
lookup. revalidate is called from lookup and it's return code is not 
checked. Even if it was the return is often success even if there is a 
mount failure.

revalidate calls try_to_fill_dentry (I think that's the function name) 
which is responsible for the false return code. Some thought about why it 
returns these would be good to do first. This may well be historic and 
overdue to be updated. If so correcting the return codes and checking 
them in lookup my be a better solution.

I'll have a closer look at the patch and the return code issue tonight.

Thanks for your continued help.

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/