On Thu, 28 Apr 2022, Prakash Sangappa wrote:
>semtimedop() should be converted to use hrtimer like it has been done
>for most of the system calls with timeouts. This system call already
>takes a struct timespec as an argument and can therefore provide finer
>granularity timed wait.
>
>Signed-off-by: Prakash Sangappa <[email protected]>
>Reviewed-by: Thomas Gleixner <[email protected]>
>---
>v1->v2:
> - Use timespec64_valid() to validate timeout
> and other changes as suggested by Thomas Gleixner
>v2-v3 Added Reviewed by tag
>---
The second '---' is not necesary, it's the first one that counts.
>@@ -2166,10 +2167,8 @@ long __do_semtimedop(int semid, struct sembuf *sops,
> sem_unlock(sma, locknum);
> rcu_read_unlock();
>
>- if (timeout)
>- jiffies_left = schedule_timeout(jiffies_left);
>- else
>- schedule();
>+ timed_out = !schedule_hrtimeout_range(exp,
>+ current->timer_slack_ns, HRTIMER_MODE_ABS);
I'm wondering if the slack parameter instead of passing the timer_slack_ns
value immediately, we should do a rt_task() check and pass zero if so.
And the opposite for the posix mqueue case: bit a little more lenient when
!rt_task() and pass current->timer_slack_ns instead of zero. Of course mq
is a lot more rt aware than sysv semaphores, but that doesn't mean both forms
of ipc are not seen used with or without RT constraints.
Thanks,
Davidlohr
On Thu, Apr 28 2022 at 13:50, Davidlohr Bueso wrote:
> On Thu, 28 Apr 2022, Prakash Sangappa wrote:
>>- if (timeout)
>>- jiffies_left = schedule_timeout(jiffies_left);
>>- else
>>- schedule();
>>+ timed_out = !schedule_hrtimeout_range(exp,
>>+ current->timer_slack_ns, HRTIMER_MODE_ABS);
>
> I'm wondering if the slack parameter instead of passing the timer_slack_ns
> value immediately, we should do a rt_task() check and pass zero if so.
We should have a wrapper function which takes care of that instead of
having checks all over the place.
Thanks,
tglx