[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #29655] linkat() fails because __file_name_lookup_at() problems

From: Emilio Pozuelo Monfort
Subject: [bug #29655] linkat() fails because __file_name_lookup_at() problems
Date: Sat, 24 Apr 2010 10:50:53 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; es-es) AppleWebKit/531.2+ (KHTML, like Gecko) Safari/531.2+ Debian/squeeze/sid () Epiphany/2.30.2


                 Summary: linkat() fails because __file_name_lookup_at()
                 Project: The GNU Hurd
            Submitted by: pochu
            Submitted on: Sat 24 Apr 2010 12:50:52 PM CEST
                Category: glibc
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Reproducibility: None
              Size (loc): None
         Planned Release: None
                  Effort: 0.00
Wiki-like text discussion box: 



While looking at the coreutils test suite failures, I found that the new ln
fails miserably for hard links:

pochu@strauss:~$ touch a && /home/pochu/coreutils-8.4/src/ln a b
/home/pochu/coreutils-8.4/src/ln: creating hard link `b' => `a': Computer
bought the farm

Samuel helped me to debug the problem and found this:

00:09 <     youpi> one difference is that the newer ln uses linkat
00:20 <     youpi> seems like the AT_SYMLINK_FOLLOW is the culprit, making
__file_name_lookup_at return -1 with errno == EINVAL
00:20 <     youpi> while __file_name_lookup is supposed to return a port, not
00:20 <     youpi> resulting to a bogus error handling
00:24 <     youpi> it seems to me like the logic in the hurd port is
inverted: susv says that by default linkat shouldn't dereference symlinks,
i.e. the flags passed by linkat should be O_NOLINK, but if.
                   AT_SYMLINK_FOLLOW is given, it should be cleared in
00:24 <     youpi> pochu: could you try this out?
00:25 <     youpi> and of course, btw, the EINVAL case should be fixed
00:26 <     youpi> (using _hurd_fail is really completely bogus here)
00:27 <     youpi> (just setting errno to EINVAL and returning MACH_PORT_NULL
should be fine)
00:35 <     pochu> youpi: so, __file_name_lookup_at() is returning -1 (bug),
which is then passed to __file_getlinknode(), which sets errno to
EMACH_SEND_INVALID_DEST, and __hurd_fail() change it to EIEIO?
00:35 <     youpi> probably yes

He was right. I first tested a one liner to return MACH_PORT_NULL instead of
-1 in __file_name_lookup_at(),

-    return __hurd_fail (EINVAL);
+    return (__hurd_fail (EINVAL), MACH_PORT_NULL);

 and with that ln failed with invalid argument:

pochu@strauss:~/coreutils-8.4/src$ LD_LIBRARY_PATH=/home/pochu/lib ./ln
/tmp/a /tmp/b
./ln: creating hard link `/tmp/b' => `/tmp/a': Invalid argument

And then I tried to fix the AT_SYMLINK_FOLLOW, and the attached patch make ln
work fine and the failing tests to pass.

Basically, __file_name_lookup_at() doesn't allow other AT_ flags than
AT_SYMLINK_NOFOLLOW, and it doesn't default to not follow links, as Samuel
said, see
"If the AT_SYMLINK_FOLLOW flag is clear in the flag argument and the path1
argument names a symbolic link, a new link is created for the symbolic link
path1 and not its target."


File Attachments:

Date: Sat 24 Apr 2010 12:50:52 PM CEST  Name: glibc-ln2.patch  Size: 2kB  
By: pochu
Fix linkat() and __file_name_lookup_at()


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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