[florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[Song Chen]

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

Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[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?

> 
> 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

Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[chensong_2000]

在 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(-)
>>
> 
> 

Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[chensong_2000]

在 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(-)
>>>
>>
>>
> 
> 

Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[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

> 
>>
>>>
>>>>
>>>> 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

Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[chensong_2000]

在 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(-)
>>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 

RE: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[dietmar.schindler]

> 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.
________________________________

Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[chensong_2000]

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.
> ________________________________
> 

Re: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[Florian Bezdeka]

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&amp;data=04%7C01%7Cflorian.bezdeka%40siemens.com%7Cb99e85555dbc4dbc8b6208d92c7f1d5f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637589746739914122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=v6x0HYNAhBs%2FgVoSsuI8hkHwrItWfYbFWXMjtVdTHiU%3D&amp;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

RE: [florian/y2038][PATCH v3 0/3] y2038:mutex_timedlock for timespec64

[dietmar.schindler]

> 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&amp;data=04%7C01%7Cflorian.bezdeka%40siemens.com%7Cb99e85555dbc4dbc8b6
> 208d92c7f1d5f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637589746739914122%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;
> sdata=v6x0HYNAhBs%2FgVoSsuI8hkHwrItWfYbFWXMjtVdTHiU%3D&amp;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.
________________________________