This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: The time(2) man page conflicts with glibc
- From: Rich Felker <dalias at libc dot org>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, linux-man <linux-man at vger dot kernel dot org>
- Date: Wed, 16 Dec 2015 17:44:32 -0500
- Subject: Re: The time(2) man page conflicts with glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOoJLk8VzyJKmkOvbmBxhCj4mVA2huYtHJsdxpatbkgJ1g at mail dot gmail dot com> <CAKCAbMj-X+wLKX3=MDm9z3L9zyikemxCNggu2bfw6=o6K5PGgg at mail dot gmail dot com> <20151215145517 dot GR11489 at vapier dot lan> <CAKCAbMh2ysZPQe3oOSjcPsx1_pcnCAQ6yf+gMbv6iDmvfnGXZA at mail dot gmail dot com> <20151215183826 dot GY11489 at vapier dot lan> <20151216070839 dot GE238 at brightrain dot aerifal dot cx> <20151216203432 dot GR11489 at vapier dot lan> <20151216215955 dot GJ238 at brightrain dot aerifal dot cx> <CAKCAbMhks8iRT6kMYUZcLRi8Y8Xj3C55OnC_yjpOdG0j4M+V-Q at mail dot gmail dot com>
On Wed, Dec 16, 2015 at 05:27:03PM -0500, Zack Weinberg wrote:
> On Wed, Dec 16, 2015 at 4:59 PM, Rich Felker <dalias@libc.org> wrote:
> >> > Programs could also be calling the syscall directly (using syscall()
> >> > or asm) and using it as a (very cheap, fail-safe) way to verify that
> >> > an address is writable before attempting to write to it. Breaking this
> >> > would be a kernel API regression. However the library function time()
> >> > has UB for invalid pointers and no obligation to support them.
> >>
> >> sure, but that still doesn't mean the kernel should be sending SEGV.
> >> which is what this subthread was about.
> >
> > The kernel is not causing SIGSEGV as far as I can tell; it's purely
> > the library function time that's causing this.
>
> .... Do you consider the vDSO to be part of the kernel, or part of the C library?
The vdso is library code provided by the kernel, but there's no
fundamental reason to expect it to behave identically to the system
call. Applications making the system call themselves directly will
never end up calling the vdso code, so it doesn't matter if its
behavior in corner cases like this is the same as the syscall.
Said differently, the vdso function is a _new_ stable kernel API
that's functionally similar to the syscall, not the same API, since
you call it in a very different way.
Rich