This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Add pthread_detach_pwd call.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha at sourceware dot org
- Date: Mon, 21 Oct 2013 10:09:48 -0400
- Subject: Re: [RFC] Add pthread_detach_pwd call.
- Authentication-results: sourceware.org; auth=none
- References: <20131020174109 dot GA17943 at domone dot podge> <20131020222505 dot GK20515 at brightrain dot aerifal dot cx> <5264FD5D dot 6040605 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310211201130 dot 23978 at digraph dot polyomino dot org dot uk> <52651E4E dot 8070707 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310211239210 dot 23978 at digraph dot polyomino dot org dot uk> <526523E8 dot 7060308 at redhat dot com>
On Mon, Oct 21, 2013 at 02:54:00PM +0200, Florian Weimer wrote:
> On 10/21/2013 02:42 PM, Joseph S. Myers wrote:
> >On Mon, 21 Oct 2013, Florian Weimer wrote:
> >>>Feel free to propose/implement new *at functions for glibc. That doesn't
> >>>depend on kernel support (although kernel support would be good) because
> >>>you can implement them in userspace using /proc/self/fd, just like many
> >>>existing fallback implementations for !__ASSUME_ATFCTS.
> >>Interesting. Is constructing such names
> >> static const char procfd = "/proc/self/fd/%d/%s";
> >>race-free? I'm asking because the /proc/self/fd entries are presented as
> >>symbolic links.
> >I don't see why this technique would involve any races different from a
> >direct syscall. In both cases, if another thread changes the file
> >descriptor at the same time as the call, you can't predict whether the old
> >or new version would be used.
> I was wondering if the kernel performs symlink resolution behind the
> scenes, or if it uses the file descriptor directly. But based on a
> quick experiment, it should be race-free. This looks rather nice.
The symlinks in /proc/$pid/fd/ are not symlinks; getdents and readlink
just falsely present them as such. They're magic entries that attach
directly to the open file description. For O_PATH file descriptors,
they're attached permanently to the inode resolved by the original
call to open.