Control: tags -1 + moreinfo
On Mon, Mar 07, 2016 at 04:21:24PM +0100, Vincent Lefevre wrote:
> Package: src:linux
> Version: 3.16.7-ckt20-1+deb8u3
> Severity: normal
>
> Under NFS, when an executable has been regenerated on a different machine,
> execve() gives me an EEXIST error. To reproduce the bug:
>
> francine:~> touch bin/tst
> francine:~> cat bin/tst
>
> cassis:~> cat tst.c
> int main (void)
> { return 0; }
> cassis:~> gcc -O3 tst.c -o tst
> cassis:~> mv tst bin/
> mv: overwrite ‘bin/tst’? y
>
> At this point, I have to wait for 15 seconds for the "mv" to be
> done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799838
>
> After that:
>
> francine:~> strace -f -o tst.out sh -c "exec $HOME/bin/tst"
> sh: 1: exec: /home/vlefevre/bin/tst: File exists
> zsh: exit 2 strace -f -o tst.out sh -c "exec $HOME/bin/tst"
> francine:~[2]> cat tst.out
> 21573 execve("/bin/sh", ["sh", "-c", "exec /home/vlefevre/bin/tst"], [/* 120
> vars */]) = 0
> 21573 brk(0) = 0x7f4aded7d000
> 21573 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> 21573 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f4aded46000
> 21573 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/tls/x86_64/libc.so.6",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/tls/x86_64",
> 0x7ffec78d5b00) = -1 ENOENT (No such file or directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/tls/libc.so.6",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/tls", 0x7ffec78d5b00) =
> -1 ENOENT (No such file or directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/x86_64/libc.so.6",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib/x86_64", 0x7ffec78d5b00)
> = -1 ENOENT (No such file or directory)
> 21573 open("/home/vlefevre/debian8/gmp/westmere/lib/libc.so.6",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> 21573 stat("/home/vlefevre/debian8/gmp/westmere/lib", {st_mode=S_IFDIR|0755,
> st_size=13, ...}) = 0
> 21573 open("/usr/local/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1
> ENOENT (No such file or directory)
> 21573 stat("/usr/local/lib/tls/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such
> file or directory)
> 21573 open("/usr/local/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> 21573 stat("/usr/local/lib/tls", 0x7ffec78d5b00) = -1 ENOENT (No such file or
> directory)
> 21573 open("/usr/local/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> 21573 stat("/usr/local/lib/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file
> or directory)
> 21573 open("/usr/local/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
> such file or directory)
> 21573 stat("/usr/local/lib", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096,
> ...}) = 0
> 21573 open("/lib64/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
> such file or directory)
> 21573 stat("/lib64/tls/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file or
> directory)
> 21573 open("/lib64/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
> 21573 stat("/lib64/tls", 0x7ffec78d5b00) = -1 ENOENT (No such file or
> directory)
> 21573 open("/lib64/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
> such file or directory)
> 21573 stat("/lib64/x86_64", 0x7ffec78d5b00) = -1 ENOENT (No such file or
> directory)
> 21573 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> 21573 read(3,
> "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 832) =
> 832
> 21573 fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
> 21573 mmap(NULL, 3844640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0x7f4ade55f000
> 21573 mprotect(0x7f4ade701000, 2093056, PROT_NONE) = 0
> 21573 mmap(0x7f4ade900000, 24576, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a1000) = 0x7f4ade900000
> 21573 mmap(0x7f4ade906000, 14880, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4ade906000
> 21573 close(3) = 0
> 21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f4aded45000
> 21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f4aded44000
> 21573 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f4aded43000
> 21573 arch_prctl(ARCH_SET_FS, 0x7f4aded44700) = 0
> 21573 mprotect(0x7f4ade900000, 16384, PROT_READ) = 0
> 21573 mprotect(0x7f4aded48000, 12288, PROT_READ) = 0
> 21573 mprotect(0x7f4adeb2a000, 4096, PROT_READ) = 0
> 21573 getpid() = 21573
> 21573 rt_sigaction(SIGCHLD, {0x7f4adeb3efd0, ~[RTMIN RT_1], SA_RESTORER,
> 0x7f4ade5940e0}, NULL, 8) = 0
> 21573 geteuid() = 1114
> 21573 brk(0) = 0x7f4aded7d000
> 21573 brk(0x7f4aded9e000) = 0x7f4aded9e000
> 21573 getppid() = 21568
> 21573 stat("/home/vlefevre", {st_mode=S_IFDIR|0751, st_size=328, ...}) = 0
> 21573 stat(".", {st_mode=S_IFDIR|0751, st_size=328, ...}) = 0
> 21573 rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
> 21573 rt_sigaction(SIGINT, {0x7f4adeb3efd0, ~[RTMIN RT_1], SA_RESTORER,
> 0x7f4ade5940e0}, NULL, 8) = 0
> 21573 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
> 21573 rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER,
> 0x7f4ade5940e0}, NULL, 8) = 0
> 21573 rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
> 21573 rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER,
> 0x7f4ade5940e0}, NULL, 8) = 0
> 21573 execve("/home/vlefevre/bin/tst", ["/home/vlefevre/bin/tst"], [/* 120
> vars */]) = -1 EEXIST (File exists)
> 21573 write(2, "sh: 1: exec: ", 13) = 13
> 21573 write(2, "/home/vlefevre/bin/tst: File exi"..., 35) = 35
> 21573 write(2, "\n", 1) = 1
> 21573 exit_group(2) = ?
> 21573 +++ exited with 2 +++
>
> According to the execve(2), this EEXIST error is not possible.
> Actually, it doesn't even make sense here since the file needs
> to exist.
I was not able to reproduce this bug (specifically under buster, with
a 4.19.181-1 kernel on both machines).
Are you still able to trigger the problem?
Regards,
Salvatore
