From: "Pádraig Brady" <P@draigBrady.com>
To: "Ludovic Courtès" <ludo@gnu.org>,
"Andy Patterson" <ajpatter@uwaterloo.ca>
Cc: bug-gnulib@gnu.org, 20597@debbugs.gnu.org
Subject: bug#20597: ‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure
Date: Sun, 24 May 2015 12:57:56 +0100 [thread overview]
Message-ID: <5561BCC4.6040604__42821.561304345$1432476243$gmane$org@draigBrady.com> (raw)
In-Reply-To: <87617i9plu.fsf_-_@gnu.org>
On 24/05/15 12:33, Ludovic Courtès wrote:
> (Please keep 20597@debbugs.gnu.org Cc'd.)
> (Gnulib: please scroll further down for the ‘unlinkat’ issue.)
>
> Andy Patterson <ajpatter@uwaterloo.ca> skribis:
>
>>> I suppose this is Guix 0.8.2 on top of another distribution, right? Did
>>> you install from source or from the binary tarball? Did you enable
>>> substitutes (info "(guix) Substitutes")?
>>
>> I was using the USB install medium in a live environment.
>
> So this is on GuixSD 0.8.2. ‘test-suite.log’ indeed mentions
> Linux-libre 4.0.2.
>
>> I had substitutes enabled (I'm pretty sure they're enabled by default
>> here, but I also enabled them manually just to be sure). I wasn't able
>> to install anything with substitutes enabled; it would always stall
>> while trying to update the substitutes list from hydra. When my
>> network went down briefly, it informed me that it was still at 0.0%
>> before exiting. I think that this is probably a separate issue, but
>> which which I was less concerned about since I didn't want to use
>> substitutes anyway.
>
> OK.
>
> hydra.gnu.org is unfortunately too often overloaded these days, so you
> probably arrived on a bad day. Nevertheless, the solution to this
> specific issue is for you to use substitutes to circumvent the bug
> described below.
>
>>> Does the build succeed if you run it another time with:
>>>
>>> guix build tar -K -c 1
>>
>> I tried this (with --no-substitutes), but I don't think the test suite
>> actually runs in parallel. I didn't notice any difference in that regard
>> when it was running; it seemed to take up the same amount of time with
>> or without -c 1. I had the same tests fail with the flag enabled.
>
> Oh you must be right. Looking at tests/Makefile.in, I see:
>
> --8<---------------cut here---------------start------------->8---
> check-local: atconfig atlocal $(TESTSUITE)
> $(SHELL) $(TESTSUITE) $(TESTSUITEFLAGS)
> --8<---------------cut here---------------end--------------->8---
>
> ... which shows that ./testsuite is not automatically passed -j,
> contrary to what I thought.
>
> <http://lists.gnu.org/archive/html/bug-tar/2014-08/msg00010.html>
> reports a similar issue but on a different OS.
>
> I just tried this in a GuixSD VM with Linux-libre 4.0.2:
>
> --8<---------------cut here---------------start------------->8---
> mkdir foo
> mkdir bar
> echo foo/foo_file > foo/foo_file
> echo bar/bar_file > bar/bar_file
> tar -cvf foo.tar --remove-files -C foo . -C ../bar .
> find .
> stat bar
> --8<---------------cut here---------------end--------------->8---
>
> And indeed, it fails (that is, ‘bar’ is left behind.) It works fine on
> 4.0.4-gnu though.
>
> On 4.0.2-gnu, I strace’d the ‘tar’ command above:
>
> --8<---------------cut here---------------start------------->8---
> openat(AT_FDCWD, "foo", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
>
> [...]
>
> openat(4, ".", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC) = 5
>
> [...]
>
> openat(5, "foo_file", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC) = 6
>
> [...]
>
> openat(4, "../bar", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
> newfstatat(5, ".", {st_mode=S_IFDIR|0755, st_size=60, ...}, AT_SYMLINK_NOFOLLOW) = 0
> openat(5, ".", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC) = 6
>
> [...]
>
> openat(6, "bar_file", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC) = 7
> fstat(7, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> write(1, "./bar_file\n", 11) = 11
> read(7, "x\n", 2) = 2
> fstat(7, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0
> close(7) = 0
> fstat(6, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
> brk(0x1a34000) = 0x1a34000
> close(6) = 0
> write(3, "./\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 10240) = 10240
> close(3) = 0
> 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?
If it was just a fleeting issue, then there is less incentive to workaround.
cheers,
Pádraig
next prev parent reply other threads:[~2015-05-24 11:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-17 7:23 bug#20597: GNU tar fails test suite Andrew Patterson
2015-05-19 15:42 ` Ludovic Courtès
[not found] ` <5561771F.2010203@uwaterloo.ca>
2015-05-24 11:33 ` bug#20597: ‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure Ludovic Courtès
[not found] ` <87617i9plu.fsf_-_@gnu.org>
2015-05-24 11:57 ` Pádraig Brady [this message]
[not found] ` <5561BCC4.6040604@draigBrady.com>
2015-05-24 13:53 ` Ludovic Courtès
[not found] ` <874mn26q0s.fsf@gnu.org>
2015-05-24 14:19 ` Pádraig Brady
[not found] ` <5561DDD7.2020107@draigBrady.com>
2015-05-24 14:48 ` Paul Eggert
2015-05-24 21:43 ` Andy Patterson
2015-05-25 12:55 ` Ludovic Courtès
2015-06-15 22:30 ` bug#20597: GNU tar fails test suite Ludovic Courtès
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='5561BCC4.6040604__42821.561304345$1432476243$gmane$org@draigBrady.com' \
--to=p@draigbrady.com \
--cc=20597@debbugs.gnu.org \
--cc=ajpatter@uwaterloo.ca \
--cc=bug-gnulib@gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/guix.git
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.