lkml.org 
[lkml]   [2021]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] ipc/mqueue: avoid sleep after wakeup
From
Date
Hi Hillf,

On 5/14/21 5:01 AM, Hillf Danton wrote:
> The pipeline waker could start doing its job once waiter releases lock and
> get the work done before waiter takes a nap, so check wait condition before
> sleep to avoid waiting the wakeup that will never come, though that does not
> hurt much thanks to timer timeouts like a second.

First: The timeout could be infinity, thus the code must not rely on a
timeout wakeup.

A wrong wait is would be a bug.


>
> Check signal for the same reason.
>
> Signed-off-by: Hillf Danton <hdanton@sina.com>
> ---
>
> --- y/ipc/mqueue.c
> +++ x/ipc/mqueue.c
> @@ -710,15 +710,24 @@ static int wq_sleep(struct mqueue_inode_
> __set_current_state(TASK_INTERRUPTIBLE);
>
> spin_unlock(&info->lock);
> - time = schedule_hrtimeout_range_clock(timeout, 0,
> - HRTIMER_MODE_ABS, CLOCK_REALTIME);
>

I do not see a bug:

We do the __set_current_state() while holding the spinlock. If there is
a wakeup, then the wakeup will change current->state to TASK_RUNNING.

schedule() will not remove us from the run queue when current->state is
TASK_RUNNING. The same applies if there are pending signals: schedule()
checks for pending signals and sets current->state to TASK_RUNNING.

Since the __set_current_state() is done while we hold info->lock, and
since the wakeup cannot happen before we have dropped the lock [because
the task that wakes us up needs the same lock], I do not see how a
wakeup could be lost.

Thus: Which issue do you see?

--

    Manfred

\
 
 \ /
  Last update: 2021-05-14 17:52    [W:0.024 / U:0.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site