All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.