Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

[Eric Blake]

[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 <address@hidden>
> 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 <address@hidden>

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature