From: ramana <ramana@intraperson.com>
To: Ian Kent <raven@themaw.net>, autofs@linux.kernel.org
Subject: Re: unacceptable bug in autofs kernel module
Date: Wed, 29 Dec 2004 09:14:10 +0530 [thread overview]
Message-ID: <41D2280A.2090502@intraperson.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0412290843030.31988@wombat.indigo.net.au>
Ian Kent wrote:
>On Tue, 28 Dec 2004, ramana wrote:
>
>
>
>>Dear developers,
>>
>>Here is the bug in autofs3 module which causing so much pain. It simply
>>stopped me from adding much more interesting features to Autodir
>>http://www.intraperson.com/autodir/
>>
>>
>
>Thanks for this.
>
>You've provided some symptoms but you haven't provided any explanation as
>to why this is a bug.
>
>Can you explain why you need the kernel to honour a lookup for an already
>deleted dentry?
>
>
If it it is deleted then it should cleanup if any and report back to the
user space autofs/autodir daemon again that this directory is missing
instead of directly reporting that entry does not exist because it is
deleted. After all that is what autofs is all about.
What is important is that -t option is user settable option. If the user
choses low value like 1 or 2 seconds these autofs directories will be
deleted more frequently. But deletion does not mean they do not exist
actually.
It it certainly bug. Let us view from user space application which is
accessing these autofs directories. Most of the time they get access to
the directories which exist and perfectly legal. And suddenly at some
time kernel decides itself and reports it does not exist even without
asking user space autofs/autodir daemon.
What is important here is, after a while, if I access it again after
ENOENT, everything works perfectly. Is not this inconsistent behavior?
Above statement is true as I tested it from user space applications for
millions of directory requests rather then looking from kernal point of
view. If I access a autofs directory for 999 times and I get ENOENT for
1 time without proper reason from user space daemon, it is certainly bug.
Thanks for your reply.
>This could be due to the way that autofs does a d_drop instead of a
>d_delete in the directory unlink callback. However, the dentry, for all
>intentional purposes, has already been deleted.
>
>
>
Regards
ramana
--
http://www.intraperson.com
next prev parent reply other threads:[~2004-12-29 3:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-28 7:51 unacceptable bug in autofs kernel module ramana
2004-12-29 1:02 ` Ian Kent
2004-12-29 3:44 ` ramana [this message]
[not found] ` <41D21C1E.8040407@intraperson.com>
[not found] ` <Pine.LNX.4.58.0412291418160.8463@wombat.indigo.net.au>
[not found] ` <41D28271.601@intraperson.com>
2004-12-30 0:38 ` Ian Kent
2004-12-30 0:47 ` Ian Kent
[not found] ` <41D370E7.9080409@intraperson.com>
2004-12-30 5:42 ` Ian Kent
2005-02-04 0:38 ` mmarion
2005-02-04 1:49 ` Ian Kent
2005-02-04 2:59 ` ramana
2005-02-05 13:46 ` ramana
-- strict thread matches above, loose matches on Subject: below --
2005-02-04 18:58 peter.a.harris
2005-03-07 19:49 ` Mike Marion
2005-02-04 19:11 Lever, Charles
2005-02-04 22:34 peter.a.harris
2005-02-25 21:22 Trinh, Ngan
2005-03-08 0:16 peter.a.harris
2005-03-08 22:53 ` Mike Marion
2005-03-21 20:54 devnull
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=41D2280A.2090502@intraperson.com \
--to=ramana@intraperson.com \
--cc=autofs@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.