[adding bug-gnulib] On 06/18/2011 12:05 PM, Santiago Vila wrote: > I can't reproduce the failure on Debian "testing" (currently using > linux-image-2.6.38-2-amd64). > > I can reproduce it, however, on the same Debian testing system if I > use the kernel currently available on "unstable" (linux-image-2.6.39-2-amd64). > > Does this mean this is a kernel bug?
On 06/19/2011 10:24 AM, Santiago Vila wrote: > For the record, this is what "git bisect" says: > > 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit > > commit 65cfc6722361570bfe255698d9cd4dccaf47570d > Author: Al Viro <v...@zeniv.linux.org.uk> > Date: Sun Mar 13 15:56:26 2011 -0400 > > readlinkat(), fchownat() and fstatat() with empty relative pathnames > > For readlinkat() we simply allow empty pathname; it will fail unless > we have dfd equal to O_PATH-opened symlink, so we are outside of > POSIX scope here. For fchownat() and fstatat() we allow AT_EMPTY_PATH; > let the caller explicitly ask for such behaviour. > > Signed-off-by: Al Viro <v...@zeniv.linux.org.uk> Yes, most likely this is a kernel and/or glibc bug. POSIX requires readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either AT_FDCWD or open on a directory. Which does strace say about the syscall made just before the gnulib test-readlink fails? I'll try and reproduce this setup myself, to decide whether gnulib should work around things while we wait for the kernel and/or glibc to bring things back into POSIX spec compliance, or to determine that test-readlink was over-strict and can be relaxed to allow the new behavior. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature