* [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 @ 2021-06-03 12:05 Song Chen 2021-06-08 6:39 ` Florian Bezdeka 0 siblings, 1 reply; 10+ messages in thread From: Song Chen @ 2021-06-03 12:05 UTC (permalink / raw) To: florian.bezdeka, xenomai This patch serial is aimed to introduce a new syscall mutex_timedlock64 which is specific for 64-bit time_t. --- v2: 1, new revision regarding review comments v3: 1, return -errno 2, throw a warning if timeout is NULL Song Chen (3): y2038: cobalt/posix/mutex: Adding mutex_timedlock64 y2038: lib/cobalt/mutex: dispatch mutex_timedlock y2038: testsuite/smokey/y2038: testcase for mutex_timedlock64 include/cobalt/uapi/syscall.h | 1 + kernel/cobalt/posix/mutex.c | 22 +++++- kernel/cobalt/posix/mutex.h | 7 ++ kernel/cobalt/posix/syscall32.c | 7 ++ kernel/cobalt/posix/syscall32.h | 4 + lib/cobalt/mutex.c | 4 + testsuite/smokey/y2038/syscall-tests.c | 136 +++++++++++++++++++++++++++++++++ 7 files changed, 180 insertions(+), 1 deletion(-) -- 2.7.4 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-03 12:05 [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 Song Chen @ 2021-06-08 6:39 ` Florian Bezdeka 2021-06-08 7:37 ` chensong_2000 0 siblings, 1 reply; 10+ messages in thread From: Florian Bezdeka @ 2021-06-08 6:39 UTC (permalink / raw) To: Song Chen, xenomai Hi Song, On 03.06.21 14:05, Song Chen wrote: > This patch serial is aimed to introduce a new syscall mutex_timedlock64 > which is specific for 64-bit time_t. > > --- > v2: > 1, new revision regarding review comments > > v3: > 1, return -errno > 2, throw a warning if timeout is NULL Will you take care of the POSIX violation as well, or should I try to find a timeslot and do it? > > Song Chen (3): > y2038: cobalt/posix/mutex: Adding mutex_timedlock64 > y2038: lib/cobalt/mutex: dispatch mutex_timedlock > y2038: testsuite/smokey/y2038: testcase for mutex_timedlock64 > > include/cobalt/uapi/syscall.h | 1 + > kernel/cobalt/posix/mutex.c | 22 +++++- > kernel/cobalt/posix/mutex.h | 7 ++ > kernel/cobalt/posix/syscall32.c | 7 ++ > kernel/cobalt/posix/syscall32.h | 4 + > lib/cobalt/mutex.c | 4 + > testsuite/smokey/y2038/syscall-tests.c | 136 +++++++++++++++++++++++++++++++++ > 7 files changed, 180 insertions(+), 1 deletion(-) > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-08 6:39 ` Florian Bezdeka @ 2021-06-08 7:37 ` chensong_2000 2021-06-08 7:51 ` chensong_2000 0 siblings, 1 reply; 10+ messages in thread From: chensong_2000 @ 2021-06-08 7:37 UTC (permalink / raw) To: Florian Bezdeka, xenomai 在 2021/6/8 下午2:39, Florian Bezdeka 写道: > Hi Song, > > On 03.06.21 14:05, Song Chen wrote: >> This patch serial is aimed to introduce a new syscall mutex_timedlock64 >> which is specific for 64-bit time_t. >> >> --- >> v2: >> 1, new revision regarding review comments >> >> v3: >> 1, return -errno >> 2, throw a warning if timeout is NULL > > Will you take care of the POSIX violation as well, or should I try to > find a timeslot and do it? I will take care of it. POSIX violation, do you mean: + /* Timeout is never read by the kernel, so NULL should be OK */ + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); + if (!smokey_assert(!ret)) + smokey_warning("POSIX mutex_timedlock64 violation detected"); + what else should i do to take care of it, sorry if i missed some information in the past emails. /Song > >> >> Song Chen (3): >> y2038: cobalt/posix/mutex: Adding mutex_timedlock64 >> y2038: lib/cobalt/mutex: dispatch mutex_timedlock >> y2038: testsuite/smokey/y2038: testcase for mutex_timedlock64 >> >> include/cobalt/uapi/syscall.h | 1 + >> kernel/cobalt/posix/mutex.c | 22 +++++- >> kernel/cobalt/posix/mutex.h | 7 ++ >> kernel/cobalt/posix/syscall32.c | 7 ++ >> kernel/cobalt/posix/syscall32.h | 4 + >> lib/cobalt/mutex.c | 4 + >> testsuite/smokey/y2038/syscall-tests.c | 136 +++++++++++++++++++++++++++++++++ >> 7 files changed, 180 insertions(+), 1 deletion(-) >> > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-08 7:37 ` chensong_2000 @ 2021-06-08 7:51 ` chensong_2000 2021-06-08 11:03 ` Florian Bezdeka 0 siblings, 1 reply; 10+ messages in thread From: chensong_2000 @ 2021-06-08 7:51 UTC (permalink / raw) To: xenomai 在 2021/6/8 下午3:37, chensong_2000--- via Xenomai 写道: > > > 在 2021/6/8 下午2:39, Florian Bezdeka 写道: >> Hi Song, >> >> On 03.06.21 14:05, Song Chen wrote: >>> This patch serial is aimed to introduce a new syscall mutex_timedlock64 >>> which is specific for 64-bit time_t. >>> >>> --- >>> v2: >>> 1, new revision regarding review comments >>> >>> v3: >>> 1, return -errno >>> 2, throw a warning if timeout is NULL >> >> Will you take care of the POSIX violation as well, or should I try to >> find a timeslot and do it? > > I will take care of it. > > POSIX violation, do you mean: > > + /* Timeout is never read by the kernel, so NULL should be OK */ > + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); > + if (!smokey_assert(!ret)) > + smokey_warning("POSIX mutex_timedlock64 violation detected"); > + > > what else should i do to take care of it, sorry if i missed some > information in the past emails. > > /Song to find out the reason it returns 0 even if timeout is NULL? > >> >>> >>> Song Chen (3): >>> y2038: cobalt/posix/mutex: Adding mutex_timedlock64 >>> y2038: lib/cobalt/mutex: dispatch mutex_timedlock >>> y2038: testsuite/smokey/y2038: testcase for mutex_timedlock64 >>> >>> include/cobalt/uapi/syscall.h | 1 + >>> kernel/cobalt/posix/mutex.c | 22 +++++- >>> kernel/cobalt/posix/mutex.h | 7 ++ >>> kernel/cobalt/posix/syscall32.c | 7 ++ >>> kernel/cobalt/posix/syscall32.h | 4 + >>> lib/cobalt/mutex.c | 4 + >>> testsuite/smokey/y2038/syscall-tests.c | 136 >>> +++++++++++++++++++++++++++++++++ >>> 7 files changed, 180 insertions(+), 1 deletion(-) >>> >> >> > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-08 7:51 ` chensong_2000 @ 2021-06-08 11:03 ` Florian Bezdeka 2021-06-09 0:37 ` chensong_2000 2021-06-10 7:03 ` dietmar.schindler 0 siblings, 2 replies; 10+ messages in thread From: Florian Bezdeka @ 2021-06-08 11:03 UTC (permalink / raw) To: chensong_2000, xenomai On 08.06.21 09:51, chensong_2000--- via Xenomai wrote: > > > 在 2021/6/8 下午3:37, chensong_2000--- via Xenomai 写道: >> >> >> 在 2021/6/8 下午2:39, Florian Bezdeka 写道: >>> Hi Song, >>> >>> On 03.06.21 14:05, Song Chen wrote: >>>> This patch serial is aimed to introduce a new syscall mutex_timedlock64 >>>> which is specific for 64-bit time_t. >>>> >>>> --- >>>> v2: >>>> 1, new revision regarding review comments >>>> >>>> v3: >>>> 1, return -errno >>>> 2, throw a warning if timeout is NULL >>> >>> Will you take care of the POSIX violation as well, or should I try to >>> find a timeslot and do it? >> >> I will take care of it. >> >> POSIX violation, do you mean: >> >> + /* Timeout is never read by the kernel, so NULL should be OK */ >> + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); >> + if (!smokey_assert(!ret)) >> + smokey_warning("POSIX mutex_timedlock64 violation detected"); >> + >> >> what else should i do to take care of it, sorry if i missed some >> information in the past emails. >> >> /Song > > to find out the reason it returns 0 even if timeout is NULL? I already had a short discussion with Philippe about that topic some time ago. See [1]. It's more or less the same as for the sem_timedwait syscall. As long as the supplied timeout is not used / read by the kernel it should be treated as "optional argument". Reason: The POSIX spec, which says: Under no circumstance shall the function fail with a timeout if the mutex can be locked immediately. The validity of the abs_timeout parameter need not be checked if the mutex can be locked immediately. To fix this violation (we return an error if no timeout is given independent from the fact if was used or not) a refactoring might be needed. Philippe already posted his idea in [1] how to do that. [1] https://xenomai.org/pipermail/xenomai/2021-March/044668.html > >> >>> >>>> >>>> Song Chen (3): >>>> y2038: cobalt/posix/mutex: Adding mutex_timedlock64 >>>> y2038: lib/cobalt/mutex: dispatch mutex_timedlock >>>> y2038: testsuite/smokey/y2038: testcase for mutex_timedlock64 >>>> >>>> include/cobalt/uapi/syscall.h | 1 + >>>> kernel/cobalt/posix/mutex.c | 22 +++++- >>>> kernel/cobalt/posix/mutex.h | 7 ++ >>>> kernel/cobalt/posix/syscall32.c | 7 ++ >>>> kernel/cobalt/posix/syscall32.h | 4 + >>>> lib/cobalt/mutex.c | 4 + >>>> testsuite/smokey/y2038/syscall-tests.c | 136 >>>> +++++++++++++++++++++++++++++++++ >>>> 7 files changed, 180 insertions(+), 1 deletion(-) >>>> >>> >>> >> >> > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-08 11:03 ` Florian Bezdeka @ 2021-06-09 0:37 ` chensong_2000 2021-06-10 7:03 ` dietmar.schindler 1 sibling, 0 replies; 10+ messages in thread From: chensong_2000 @ 2021-06-09 0:37 UTC (permalink / raw) To: Florian Bezdeka, xenomai 在 2021/6/8 下午7:03, Florian Bezdeka 写道: > On 08.06.21 09:51, chensong_2000--- via Xenomai wrote: >> >> >> 在 2021/6/8 下午3:37, chensong_2000--- via Xenomai 写道: >>> >>> >>> 在 2021/6/8 下午2:39, Florian Bezdeka 写道: >>>> Hi Song, >>>> >>>> On 03.06.21 14:05, Song Chen wrote: >>>>> This patch serial is aimed to introduce a new syscall mutex_timedlock64 >>>>> which is specific for 64-bit time_t. >>>>> >>>>> --- >>>>> v2: >>>>> 1, new revision regarding review comments >>>>> >>>>> v3: >>>>> 1, return -errno >>>>> 2, throw a warning if timeout is NULL >>>> >>>> Will you take care of the POSIX violation as well, or should I try to >>>> find a timeslot and do it? >>> >>> I will take care of it. >>> >>> POSIX violation, do you mean: >>> >>> + /* Timeout is never read by the kernel, so NULL should be OK */ >>> + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); >>> + if (!smokey_assert(!ret)) >>> + smokey_warning("POSIX mutex_timedlock64 violation detected"); >>> + >>> >>> what else should i do to take care of it, sorry if i missed some >>> information in the past emails. >>> >>> /Song >> >> to find out the reason it returns 0 even if timeout is NULL? > > I already had a short discussion with Philippe about that topic some > time ago. See [1]. > > It's more or less the same as for the sem_timedwait syscall. As long as > the supplied timeout is not used / read by the kernel it should be > treated as "optional argument". Reason: The POSIX spec, which says: > > > Under no circumstance shall the function fail with a timeout if the > mutex can be locked immediately. The validity of the abs_timeout > parameter need not be checked if the mutex can be locked immediately. > > > To fix this violation (we return an error if no timeout is given > independent from the fact if was used or not) a refactoring might be > needed. Philippe already posted his idea in [1] how to do that. > > [1] https://xenomai.org/pipermail/xenomai/2021-March/044668.html > Thanks, i will take care of this case. Song >> >>> >>>> >>>>> >>>>> Song Chen (3): >>>>> y2038: cobalt/posix/mutex: Adding mutex_timedlock64 >>>>> y2038: lib/cobalt/mutex: dispatch mutex_timedlock >>>>> y2038: testsuite/smokey/y2038: testcase for mutex_timedlock64 >>>>> >>>>> include/cobalt/uapi/syscall.h | 1 + >>>>> kernel/cobalt/posix/mutex.c | 22 +++++- >>>>> kernel/cobalt/posix/mutex.h | 7 ++ >>>>> kernel/cobalt/posix/syscall32.c | 7 ++ >>>>> kernel/cobalt/posix/syscall32.h | 4 + >>>>> lib/cobalt/mutex.c | 4 + >>>>> testsuite/smokey/y2038/syscall-tests.c | 136 >>>>> +++++++++++++++++++++++++++++++++ >>>>> 7 files changed, 180 insertions(+), 1 deletion(-) >>>>> >>>> >>>> >>> >>> >> > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-08 11:03 ` Florian Bezdeka 2021-06-09 0:37 ` chensong_2000 @ 2021-06-10 7:03 ` dietmar.schindler 2021-06-11 2:17 ` chensong_2000 1 sibling, 1 reply; 10+ messages in thread From: dietmar.schindler @ 2021-06-10 7:03 UTC (permalink / raw) To: xenomai > From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Florian Bezdeka via Xenomai > Sent: Tuesday, June 8, 2021 1:04 PM > To: chensong_2000@189.cn; xenomai@xenomai.org > Subject: Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 > > On 08.06.21 09:51, chensong_2000--- via Xenomai wrote: > > > > > > 在 2021/6/8 下午3:37, chensong_2000--- via Xenomai 写道: > >> > >> > >> 在 2021/6/8 下午2:39, Florian Bezdeka 写道: > >>> Hi Song, > >>> > >>> On 03.06.21 14:05, Song Chen wrote: > >>>> This patch serial is aimed to introduce a new syscall mutex_timedlock64 > >>>> which is specific for 64-bit time_t. > >>>> > >>>> --- > >>>> v2: > >>>> 1, new revision regarding review comments > >>>> > >>>> v3: > >>>> 1, return -errno > >>>> 2, throw a warning if timeout is NULL > >>> > >>> Will you take care of the POSIX violation as well, or should I try to > >>> find a timeslot and do it? > >> > >> I will take care of it. > >> > >> POSIX violation, do you mean: > >> > >> + /* Timeout is never read by the kernel, so NULL should be OK */ > >> + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); > >> + if (!smokey_assert(!ret)) > >> + smokey_warning("POSIX mutex_timedlock64 violation detected"); > >> + > >> > >> what else should i do to take care of it, sorry if i missed some > >> information in the past emails. > >> > >> /Song > > > > to find out the reason it returns 0 even if timeout is NULL? > > I already had a short discussion with Philippe about that topic some > time ago. See [1]. > > It's more or less the same as for the sem_timedwait syscall. As long as > the supplied timeout is not used / read by the kernel it should be > treated as "optional argument". Reason: The POSIX spec, which says: > > > Under no circumstance shall the function fail with a timeout if the > mutex can be locked immediately. The validity of the abs_timeout > parameter need not be checked if the mutex can be locked immediately. > > > To fix this violation (we return an error if no timeout is given > independent from the fact if was used or not) a refactoring might be > needed. Philippe already posted his idea in [1] how to do that. > > [1] https://xenomai.org/pipermail/xenomai/2021-March/044668.html Please excuse my jumping in the discussion - perhaps I'm missing something, but IMHO "need not be checked" does not mean "must not be checked", but rather implies "may be checked", so a mere validity check is not a violation of POSIX. You, Florian, in [1] just said about the validating: "Yes it does, and probably should not for consistency with other calls" - that's a different, also fair reason for avoiding the check. -- Best regards, Dietmar ________________________________ manroland Goss web systems GmbH | Managing Director: Franz Kriechbaum Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: 32609 | VAT: DE815764857 Confidentiality note: This message and any attached documents may contain confidential or proprietary information of manroland|Goss. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. If you have received this communication in error, please immediately notify the sender and delete the message from your system. All liability for viruses is excluded to the fullest extent permitted by law. ________________________________ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-10 7:03 ` dietmar.schindler @ 2021-06-11 2:17 ` chensong_2000 2021-06-11 7:28 ` Florian Bezdeka 0 siblings, 1 reply; 10+ messages in thread From: chensong_2000 @ 2021-06-11 2:17 UTC (permalink / raw) To: xenomai hi Dietmar, 在 2021/6/10 下午3:03, Dietmar Schindler via Xenomai 写道: >> From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Florian Bezdeka via Xenomai >> Sent: Tuesday, June 8, 2021 1:04 PM >> To: chensong_2000@189.cn; xenomai@xenomai.org >> Subject: Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 >> >> On 08.06.21 09:51, chensong_2000--- via Xenomai wrote: >>> >>> >>> 在 2021/6/8 下午3:37, chensong_2000--- via Xenomai 写道: >>>> >>>> >>>> 在 2021/6/8 下午2:39, Florian Bezdeka 写道: >>>>> Hi Song, >>>>> >>>>> On 03.06.21 14:05, Song Chen wrote: >>>>>> This patch serial is aimed to introduce a new syscall mutex_timedlock64 >>>>>> which is specific for 64-bit time_t. >>>>>> >>>>>> --- >>>>>> v2: >>>>>> 1, new revision regarding review comments >>>>>> >>>>>> v3: >>>>>> 1, return -errno >>>>>> 2, throw a warning if timeout is NULL >>>>> >>>>> Will you take care of the POSIX violation as well, or should I try to >>>>> find a timeslot and do it? >>>> >>>> I will take care of it. >>>> >>>> POSIX violation, do you mean: >>>> >>>> + /* Timeout is never read by the kernel, so NULL should be OK */ >>>> + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); >>>> + if (!smokey_assert(!ret)) >>>> + smokey_warning("POSIX mutex_timedlock64 violation detected"); >>>> + >>>> >>>> what else should i do to take care of it, sorry if i missed some >>>> information in the past emails. >>>> >>>> /Song >>> >>> to find out the reason it returns 0 even if timeout is NULL? >> >> I already had a short discussion with Philippe about that topic some >> time ago. See [1]. >> >> It's more or less the same as for the sem_timedwait syscall. As long as >> the supplied timeout is not used / read by the kernel it should be >> treated as "optional argument". Reason: The POSIX spec, which says: >> >> >> Under no circumstance shall the function fail with a timeout if the >> mutex can be locked immediately. The validity of the abs_timeout >> parameter need not be checked if the mutex can be locked immediately. >> >> >> To fix this violation (we return an error if no timeout is given >> independent from the fact if was used or not) a refactoring might be >> needed. Philippe already posted his idea in [1] how to do that. >> >> [1] https://xenomai.org/pipermail/xenomai/2021-March/044668.html > > Please excuse my jumping in the discussion - perhaps I'm missing something, but IMHO "need not be checked" does not mean "must not be checked", but rather implies "may be checked", so a mere validity check is not a violation of POSIX. You, Florian, in [1] just said about the validating: "Yes it does, and probably should not for consistency with other calls" - that's a different, also fair reason for avoiding the check. you are so welcomed to join the discussion and your opinion is valued and helpful. we have three cases about validating timeout: 1) sem_timedwait it merely validates timeout, not returns error back to user space even it fails, same with what you said. 2) mutex_timedlock it acts differently with sem_timedwait, if timeout is null, returns -EFAULT before trying to acquire 3) mq_timedsend/mq_timedreceive if it manages to send msg to the queue, it even doesn't validate timeout at all. however, in vanilla kernel, it validates timeout at the beginning and return EFAULT if it fails, as a result, mq_timedsend/mq_timedreceive has different semantics, returns different values and leads to different behaviors in user space. I would suggest we should follow vanilla kernel, what do you think? what's more, i didn't find implementation of sem_timedwait and mutex_timedlock, are they in glibc? then we should follow glibc. > > -- > Best regards, > Dietmar > ________________________________ > manroland Goss web systems GmbH | Managing Director: Franz Kriechbaum > Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: 32609 | VAT: DE815764857 > > Confidentiality note: > This message and any attached documents may contain confidential or proprietary information of manroland|Goss. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. If you have received this communication in error, please immediately notify the sender and delete the message from your system. All liability for viruses is excluded to the fullest extent permitted by law. > ________________________________ > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-11 2:17 ` chensong_2000 @ 2021-06-11 7:28 ` Florian Bezdeka 2021-06-15 13:14 ` dietmar.schindler 0 siblings, 1 reply; 10+ messages in thread From: Florian Bezdeka @ 2021-06-11 7:28 UTC (permalink / raw) To: chensong_2000, xenomai, dietmar.schindler On 11.06.21 04:17, chensong_2000--- via Xenomai wrote: > hi Dietmar, > > 在 2021/6/10 下午3:03, Dietmar Schindler via Xenomai 写道: >>> From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Florian >>> Bezdeka via Xenomai >>> Sent: Tuesday, June 8, 2021 1:04 PM >>> To: chensong_2000@189.cn; xenomai@xenomai.org >>> Subject: Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for >>> timespec64 >>> >>> On 08.06.21 09:51, chensong_2000--- via Xenomai wrote: >>>> >>>> >>>> 在 2021/6/8 下午3:37, chensong_2000--- via Xenomai 写道: >>>>> >>>>> >>>>> 在 2021/6/8 下午2:39, Florian Bezdeka 写道: >>>>>> Hi Song, >>>>>> >>>>>> On 03.06.21 14:05, Song Chen wrote: >>>>>>> This patch serial is aimed to introduce a new syscall >>>>>>> mutex_timedlock64 >>>>>>> which is specific for 64-bit time_t. >>>>>>> >>>>>>> --- >>>>>>> v2: >>>>>>> 1, new revision regarding review comments >>>>>>> >>>>>>> v3: >>>>>>> 1, return -errno >>>>>>> 2, throw a warning if timeout is NULL >>>>>> >>>>>> Will you take care of the POSIX violation as well, or should I try to >>>>>> find a timeslot and do it? >>>>> >>>>> I will take care of it. >>>>> >>>>> POSIX violation, do you mean: >>>>> >>>>> + /* Timeout is never read by the kernel, so NULL should be OK */ >>>>> + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); >>>>> + if (!smokey_assert(!ret)) >>>>> + smokey_warning("POSIX mutex_timedlock64 violation detected"); >>>>> + >>>>> >>>>> what else should i do to take care of it, sorry if i missed some >>>>> information in the past emails. >>>>> >>>>> /Song >>>> >>>> to find out the reason it returns 0 even if timeout is NULL? >>> >>> I already had a short discussion with Philippe about that topic some >>> time ago. See [1]. >>> >>> It's more or less the same as for the sem_timedwait syscall. As long as >>> the supplied timeout is not used / read by the kernel it should be >>> treated as "optional argument". Reason: The POSIX spec, which says: >>> >>> >>> Under no circumstance shall the function fail with a timeout if the >>> mutex can be locked immediately. The validity of the abs_timeout >>> parameter need not be checked if the mutex can be locked immediately. >>> >>> >>> To fix this violation (we return an error if no timeout is given >>> independent from the fact if was used or not) a refactoring might be >>> needed. Philippe already posted his idea in [1] how to do that. >>> >>> [1] >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxenomai.org%2Fpipermail%2Fxenomai%2F2021-March%2F044668.html&data=04%7C01%7Cflorian.bezdeka%40siemens.com%7Cb99e85555dbc4dbc8b6208d92c7f1d5f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637589746739914122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v6x0HYNAhBs%2FgVoSsuI8hkHwrItWfYbFWXMjtVdTHiU%3D&reserved=0 >>> >> >> Please excuse my jumping in the discussion - perhaps I'm missing >> something, but IMHO "need not be checked" does not mean "must not be >> checked", but rather implies "may be checked", so a mere validity >> check is not a violation of POSIX. You, Florian, in [1] just said >> about the validating: "Yes it does, and probably should not for >> consistency with other calls" - that's a different, also fair reason >> for avoiding the check. "Yes it does, and probably should not for consistency with other calls" were Philippe's words ;-) > > you are so welcomed to join the discussion and your opinion is valued > and helpful. > > we have three cases about validating timeout: > 1) sem_timedwait > it merely validates timeout, not returns error back to user space even > it fails, same with what you said. It validates the timeout before first use (not on kernel entry like below). If validation fails it will report the error. > > 2) mutex_timedlock > it acts differently with sem_timedwait, if timeout is null, returns > -EFAULT before trying to acquire Let's focus on this one first. I haven't looked at the follwing (mq) yet. POSIX again: The validity of the abs_timeout parameter need not be checked if the mutex can be locked immediately. IOW: Calling mutex_timedwait() on an mutex that is not taken for sure (the caller knows that) with an invalid/NULL timeout should succeed because there is no need to touch/validate the given timeout. Currently we fail. Maybe the wording "violation" is to hard here... > > 3) mq_timedsend/mq_timedreceive > if it manages to send msg to the queue, it even doesn't validate timeout > at all. > > however, in vanilla kernel, it validates timeout at the beginning and > return EFAULT if it fails, as a result, mq_timedsend/mq_timedreceive has > different semantics, returns different values and leads to different > behaviors in user space. > > I would suggest we should follow vanilla kernel, what do you think? > > what's more, i didn't find implementation of sem_timedwait and > mutex_timedlock, are they in glibc? then we should follow glibc. > > >> >> -- >> Best regards, >> Dietmar >> ________________________________ >> manroland Goss web systems GmbH | Managing Director: Franz Kriechbaum >> Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: >> 32609 | VAT: DE815764857 >> >> Confidentiality note: >> This message and any attached documents may contain confidential or >> proprietary information of manroland|Goss. These materials are >> intended only for the use of the intended recipient. If you are not >> the intended recipient of this transmission, you are hereby notified >> that any distribution, disclosure, printing, copying, storage, >> modification or the taking of any action in reliance upon this >> transmission is strictly prohibited. Delivery of this message to any >> person other than the intended recipient shall not compromise or waive >> such confidentiality, privilege or exemption from disclosure as to >> this communication. If you have received this communication in error, >> please immediately notify the sender and delete the message from your >> system. All liability for viruses is excluded to the fullest extent >> permitted by law. >> ________________________________ >> > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 2021-06-11 7:28 ` Florian Bezdeka @ 2021-06-15 13:14 ` dietmar.schindler 0 siblings, 0 replies; 10+ messages in thread From: dietmar.schindler @ 2021-06-15 13:14 UTC (permalink / raw) To: xenomai > From: Florian Bezdeka <florian.bezdeka@siemens.com> > Sent: Friday, June 11, 2021 9:29 AM > To: chensong_2000@189.cn; xenomai@xenomai.org; Schindler, Dietmar - OTPS > <dietmar.schindler@manrolandgoss.com> > > On 11.06.21 04:17, chensong_2000--- via Xenomai wrote: > > hi Dietmar, > > > > 在 2021/6/10 下午3:03, Dietmar Schindler via Xenomai 写道: > >>> From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Florian > >>> Bezdeka via Xenomai > >>> Sent: Tuesday, June 8, 2021 1:04 PM > >>> To: chensong_2000@189.cn; xenomai@xenomai.org > >>> Subject: Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for > >>> timespec64 > >>> > >>> On 08.06.21 09:51, chensong_2000--- via Xenomai wrote: > >>>> > >>>> > >>>> 在 2021/6/8 下午3:37, chensong_2000--- via Xenomai 写道: > >>>>> > >>>>> > >>>>> 在 2021/6/8 下午2:39, Florian Bezdeka 写道: > >>>>>> Hi Song, > >>>>>> > >>>>>> On 03.06.21 14:05, Song Chen wrote: > >>>>>>> This patch serial is aimed to introduce a new syscall > >>>>>>> mutex_timedlock64 > >>>>>>> which is specific for 64-bit time_t. > >>>>>>> > >>>>>>> --- > >>>>>>> v2: > >>>>>>> 1, new revision regarding review comments > >>>>>>> > >>>>>>> v3: > >>>>>>> 1, return -errno > >>>>>>> 2, throw a warning if timeout is NULL > >>>>>> > >>>>>> Will you take care of the POSIX violation as well, or should I try to > >>>>>> find a timeslot and do it? > >>>>> > >>>>> I will take care of it. > >>>>> > >>>>> POSIX violation, do you mean: > >>>>> > >>>>> + /* Timeout is never read by the kernel, so NULL should be OK */ > >>>>> + ret = XENOMAI_SYSCALL2(sr_nc, &lock, NULL); > >>>>> + if (!smokey_assert(!ret)) > >>>>> + smokey_warning("POSIX mutex_timedlock64 violation detected"); > >>>>> + > >>>>> > >>>>> what else should i do to take care of it, sorry if i missed some > >>>>> information in the past emails. > >>>>> > >>>>> /Song > >>>> > >>>> to find out the reason it returns 0 even if timeout is NULL? > >>> > >>> I already had a short discussion with Philippe about that topic some > >>> time ago. See [1]. > >>> > >>> It's more or less the same as for the sem_timedwait syscall. As long as > >>> the supplied timeout is not used / read by the kernel it should be > >>> treated as "optional argument". Reason: The POSIX spec, which says: > >>> > >>> > >>> Under no circumstance shall the function fail with a timeout if the > >>> mutex can be locked immediately. The validity of the abs_timeout > >>> parameter need not be checked if the mutex can be locked immediately. > >>> > >>> > >>> To fix this violation (we return an error if no timeout is given > >>> independent from the fact if was used or not) a refactoring might be > >>> needed. Philippe already posted his idea in [1] how to do that. > >>> > >>> [1] > >>> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxenomai.org%2Fpipermail% > 2Fxenomai%2F2021- > March%2F044668.html&data=04%7C01%7Cflorian.bezdeka%40siemens.com%7Cb99e85555dbc4dbc8b6 > 208d92c7f1d5f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637589746739914122%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > sdata=v6x0HYNAhBs%2FgVoSsuI8hkHwrItWfYbFWXMjtVdTHiU%3D&reserved=0 > >>> > >> > >> Please excuse my jumping in the discussion - perhaps I'm missing > >> something, but IMHO "need not be checked" does not mean "must not be > >> checked", but rather implies "may be checked", so a mere validity > >> check is not a violation of POSIX. You, Florian, in [1] just said > >> about the validating: "Yes it does, and probably should not for > >> consistency with other calls" - that's a different, also fair reason > >> for avoiding the check. > > "Yes it does, and probably should not for consistency with other calls" > were Philippe's words ;-) My apologies to you and Philippe! > > > > you are so welcomed to join the discussion and your opinion is valued > > and helpful. Thank you, Song, for the friendly words! > > > > we have three cases about validating timeout: > > 1) sem_timedwait > > it merely validates timeout, not returns error back to user space even > > it fails, same with what you said. > > It validates the timeout before first use (not on kernel entry like > below). If validation fails it will report the error. > > > > > 2) mutex_timedlock > > it acts differently with sem_timedwait, if timeout is null, returns > > -EFAULT before trying to acquire > > Let's focus on this one first. I haven't looked at the follwing (mq) yet. > > POSIX again: > > The validity of the abs_timeout parameter need not be checked if the > mutex can be locked immediately. > > IOW: Calling mutex_timedwait() on an mutex that is not taken for sure > (the caller knows that) with an invalid/NULL timeout should succeed > because there is no need to touch/validate the given timeout. Currently > we fail. > > Maybe the wording "violation" is to hard here... I agree, of course, since I don't see it as a violation at all. :-) > > 3) mq_timedsend/mq_timedreceive > > if it manages to send msg to the queue, it even doesn't validate timeout > > at all. > > > > however, in vanilla kernel, it validates timeout at the beginning and > > return EFAULT if it fails, as a result, mq_timedsend/mq_timedreceive has > > different semantics, returns different values and leads to different > > behaviors in user space. > > > > I would suggest we should follow vanilla kernel, what do you think? > > > > what's more, i didn't find implementation of sem_timedwait and > > mutex_timedlock, are they in glibc? then we should follow glibc. Again I agree that "consistency with other calls" is a good thing. -- Best regards, Dietmar Schindler ________________________________ manroland Goss web systems GmbH | Managing Director: Franz Kriechbaum Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: 32609 | VAT: DE815764857 Confidentiality note: This message and any attached documents may contain confidential or proprietary information of manroland|Goss. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. If you have received this communication in error, please immediately notify the sender and delete the message from your system. All liability for viruses is excluded to the fullest extent permitted by law. ________________________________ ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-06-15 13:14 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-03 12:05 [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64 Song Chen 2021-06-08 6:39 ` Florian Bezdeka 2021-06-08 7:37 ` chensong_2000 2021-06-08 7:51 ` chensong_2000 2021-06-08 11:03 ` Florian Bezdeka 2021-06-09 0:37 ` chensong_2000 2021-06-10 7:03 ` dietmar.schindler 2021-06-11 2:17 ` chensong_2000 2021-06-11 7:28 ` Florian Bezdeka 2021-06-15 13:14 ` dietmar.schindler
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.