[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFhhQJTYBhP1pf-UD7qPE1bxymUsJiH4Djf0JOVmjjaUgpV5oQ@mail.gmail.com>
Date: Sun, 18 Sep 2016 15:01:47 -0400
From: Daniel Sabogal <dsabogalcc@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v2] fix clock_nanosleep error case
On Sat, Sep 17, 2016 at 11:38 PM, Rich Felker <dalias@...c.org> wrote:
> On Sat, Sep 17, 2016 at 12:05:45PM -0400, Daniel Sabogal wrote:
>> posix requires that EINVAL be returned if the first parameter specifies
>> the cpu-time clock of the calling thread (CLOCK_THREAD_CPUTIME_ID).
>> linux returns ENOTSUP instead so we handle this.
>> ---
>> Applied Szabolcs' suggestion for remapping the return value.
>> clock_nanosleep is required to be a cancellation point.
>> ---
>> src/time/clock_nanosleep.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/time/clock_nanosleep.c b/src/time/clock_nanosleep.c
>> index ec87b9e..9e4d9f1 100644
>> --- a/src/time/clock_nanosleep.c
>> +++ b/src/time/clock_nanosleep.c
>> @@ -1,8 +1,10 @@
>> #include <time.h>
>> +#include <errno.h>
>> #include "syscall.h"
>> #include "libc.h"
>>
>> int clock_nanosleep(clockid_t clk, int flags, const struct timespec *req, struct timespec *rem)
>> {
>> - return -__syscall_cp(SYS_clock_nanosleep, clk, flags, req, rem);
>> + int r = -__syscall_cp(SYS_clock_nanosleep, clk, flags, req, rem);
>> + return clk == CLOCK_THREAD_CPUTIME_ID ? EINVAL : r;
>> }
>
> See:
>
> On Sat, Sep 17, 2016 at 04:57:09PM +0200, Szabolcs Nagy wrote:
>> you elide a cancellation point here.
>>
>> i think you should check and remap the return value instead.
>
> "Remap the return value" would be more like:
>
> return r==ENOTSUP ? EINVAL : r;
I wasn't sure about remapping all return values of ENOTSUP to EINVAL.
There are other clocks (extensions) where linux and glibc return ENOTSUP.
I looked through Debian Code Search, but didn't really find anything that
actually uses or depends on such behavior for those extensions.
I suppose this might be fine.
> I don't know if it makes a big difference, but in principle it's
> better to base conditions on a return value than an argument, since
> basing them on an argument requires the value of that argument to be
> preserved across the call and can thereby require spilling registers,
> etc. I don't think that actually happens on any of the Linux syscall
> ABIs but I'm not sure.
OK.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
