From: "Pádraig Brady" <P@draigBrady.com>
To: "Ludovic Courtès" <ludo@gnu.org>, "Paul Eggert" <eggert@cs.ucla.edu>
Cc: 21460@debbugs.gnu.org, Assaf Gordon <assafgordon@gmail.com>,
bug-guix@gnu.org
Subject: bug#21460: Race condition in tests/tail-2/assert.sh
Date: Sat, 12 Sep 2015 00:48:36 +0100 [thread overview]
Message-ID: <55F36854.90306@draigBrady.com> (raw)
In-Reply-To: <55F35A96.2090906@draigBrady.com>
On 11/09/15 23:49, Pádraig Brady wrote:
> On 11/09/15 21:55, Ludovic Courtès wrote:
>> Paul Eggert <eggert@cs.ucla.edu> skribis:
>>
>>> Ludovic Courtès wrote:
>>>> I think the problem happens when ‘tail’ opens ‘foo’ right in between of
>>>> the two notifications: ‘foo’ is still there, and so ‘tail’ doesn’t
>>>> report anything.
>>>>
>>>> Does that make sense?
>>>
>>> Yes, though if the link count is indeed zero, I'm surprised that
>>> 'tail' can open the file -- that sounds like a bug in the kernel.
>>
>> Attached is a reproducer; just run it in a loop for a couple of seconds:
>>
>> --8<---------------cut here---------------start------------->8---
>> $ while ./a.out ; do : ; done
>> funny, errno = Success, nlink = 0
>> Aborted (core dumped)
>> --8<---------------cut here---------------end--------------->8---
>>
>> I’m not sure if that’s a kernel bug. Strictly speaking, inotify works
>> as expected: we get a notification for nlink--, which doesn’t mean the
>> file has vanished.
>
> Interesting. It does seem that the IN_ATTRIB is sent before the st_nlink--
> takes effect? That could be a bug. Or it could be a dcache coherency
> issue where the name still references the st_nlink==0 inode.
>
> Note recheck() just open() and close() the file in this case,
> but since it doesn't close() the original fd, then there will be
> no IN_DELETE_SELF event.
>
> If the above kernel behavior can be explained and is acceptable,
> I suppose we could augment recheck() with something like:
>
> diff --git a/src/tail.c b/src/tail.c
> index f916d74..e9d5337 100644
> --- a/src/tail.c
> +++ b/src/tail.c
> @@ -1046,6 +1046,18 @@ recheck (struct File_spec *f, bool blocking)
> close_fd (f->fd, pretty_name (f));
>
> }
> + else if (new_stats.st_nlink == 0) /* XXX: what about multi-linked files. */
> + {
> + /* It was seen on Linux that a file could be opened
> + even though unlinked as the directory entry (cache)
> + is updated after the IN_ATTRIB is sent for the nlink--. */
> +
> + error (0, f->errnum, _("%s has become inaccessible"),
> + quote (pretty_name (f)));
> +
> + close_fd (fd, pretty_name (f));
> + close_fd (f->fd, pretty_name (f));
> + f->fd = -1;
> + }
> else
> {
>
>> The conclusion for ‘tail’ would be to wait for the IN_DELETE_SELF event
>> before considering the file to be gone. WDYT?
>
> As mentioned above, tail references the file until it can't open it,
> so the IN_DELETE_SELF is only generated upon the close_fd(f->fd) above.
Google reminded me of this!
https://lists.gnu.org/archive/html/coreutils/2015-07/msg00015.html
I.E. this is the same issue that Assaf noticed,
and that I though was restricted to older kernels.
That has an alternate fix attached.
cheers,
Pádraig.
next prev parent reply other threads:[~2015-09-11 23:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 16:23 bug#21459: Race condition in tests/tail-2/assert.sh Ludovic Courtès
2015-09-11 17:18 ` bug#21460: " Paul Eggert
2015-09-11 20:55 ` Ludovic Courtès
2015-09-11 22:49 ` Pádraig Brady
2015-09-11 23:48 ` Pádraig Brady [this message]
2015-09-12 1:09 ` Paul Eggert
2015-09-12 2:22 ` Pádraig Brady
2015-10-02 15:50 ` Pádraig Brady
2015-09-11 20:34 ` bug#21459: " Pádraig Brady
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F36854.90306@draigBrady.com \
--to=p@draigbrady.com \
--cc=21460@debbugs.gnu.org \
--cc=assafgordon@gmail.com \
--cc=bug-guix@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=ludo@gnu.org \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).