[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure
From: |
Pádraig Brady |
Subject: |
Re: ‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure |
Date: |
Sun, 24 May 2015 15:19:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
On 24/05/15 14:53, Ludovic Courtès wrote:
> Pádraig Brady <address@hidden> skribis:
>
>> On 24/05/15 12:33, Ludovic Courtès wrote:
>
> [...]
>
>>> unlinkat(4, "foo_file", 0) = 0
>>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0
>>> unlinkat(5, "bar_file", 0) = 0
>>> unlinkat(4, "../bar", AT_REMOVEDIR) = -1 ENOENT (No such file or
>>> directory)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Contrast this with the same thing on 4.0.4-gnu:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> unlinkat(4, "foo_file", 0) = 0
>>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0
>>> unlinkat(5, "bar_file", 0) = 0
>>> unlinkat(4, "../bar", AT_REMOVEDIR) = 0
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> So this looks like a 4.0.2 kernel bug that Gnulib’s unlinkat should
>>> perhaps work around.
>>>
>>> Thoughts?
>>
>> Maybe. How widely deployed was 4.0.2 (It's not used in Red Hat land for
>> example).
>> How many versions was the bug present for?
>
> I don’t know, and I haven’t been able to find traces of a fix in that
> area in the kernel.
>
> OTOH, after rereading the analysis at
> <http://lists.gnu.org/archive/html/bug-tar/2014-08/msg00010.html>, it
> may be that the 4.0.2 behavior is POSIX-conforming, in which case we’d
> rather fix tar (or its tests) instead:
>
> The BSD behavior appears to be in line with POSIX. unlinkat() with
> AT_REMOVEDIR is equivalent to rmdir(), whose specification says:
>
> If one or more processes have the directory open when the last
> link is removed, the dot and dot-dot entries, if present, shall
> be removed before rmdir() returns and no new entries may be created
> in the directory, but the directory shall not be removed until
> all references to the directory are closed.
>
> Without "..", the path resolution of the subsequent unlinkat() call
> should--or at least can--fail.
>
> WDYT?
Yes I agree, either behavior is possible
thanks,
Pádraig