mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Ian Kent <raven@themaw.net>
Cc: autofs@linux.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: autofs4 looks up wrong path element when ghosting is enabled
Date: Mon, 26 Sep 2005 11:14:40 -0400	[thread overview]
Message-ID: <17208.4192.84732.418313@segfault.boston.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0509250918150.2191@donald.themaw.net>

==> Regarding Re: autofs4 looks up wrong path element when ghosting is enabled; Ian Kent <raven@themaw.net> 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.

Ian, this will introduce a regression.  That code was changed to fix a
different bug with ghosted direct maps.  So, at least for autofs4, this
isn't a good fix.  To be more specific, the problem comes when you update a
ghosted direct map.  So, if you had a direct map that looks like:

/opt/local/bin server:/export/local/bin

An ls of /opt/local would show the 'bin' directory.  If we update the map,
adding this entry:

/opt/local/share	server:/export/local/share

An ls of '/opt/local/share' will return -ENOENT.  The current behaviour is
to list the contents of /opt/local/share, which is correct.

-Jeff

  reply	other threads:[~2005-09-26 15:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-20 19:02 Jeff Moyer
2005-09-21  1:25 ` Ian Kent
2005-09-22 21:09   ` Jeff Moyer
2005-09-24  8:59     ` Ian Kent
2005-09-24 20:51       ` Jeff Moyer
2005-09-25  1:25         ` Ian Kent
2005-09-26 15:14           ` Jeff Moyer [this message]
2005-09-27  4:21             ` Ian Kent
2005-09-26 20:57           ` Jeff Moyer
2005-09-27  4:34             ` Ian Kent
2005-10-08  5:43             ` Ian Kent
2005-10-08 12:50               ` Jeff Moyer
2005-10-09  4:29                 ` Ian Kent
2005-10-15 12:30             ` Ian Kent
2005-10-19 20:49               ` Jeff Moyer
2005-10-20  0:50                 ` Ian Kent
2005-10-29  7:42                 ` Ian Kent
2005-10-31 11:33                   ` Jeff Moyer
2005-10-31 13:27                     ` Ian Kent
2005-11-05  9:50                       ` [autofs] " Ian Kent
2005-11-10 23:51                         ` Jeff Moyer
2005-11-11 14:53                           ` Ian Kent

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=17208.4192.84732.418313@segfault.boston.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=autofs@linux.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raven@themaw.net \
    /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

all inboxes | Powered by JetHome®