bug-gnulib
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]