In "autofs4: use wait_event_killable", wait_event_interruptible() was
replaced by wait_event_killable(), but in this case we have to use
wake_up() instead of wake_up_interruptible().
Cc: Matthew Wilcox <[email protected]>
Cc: Ian Kent <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Signed-off-by: Andrei Vagin <[email protected]>
---
fs/autofs4/waitq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
index c160e9b3aa0f..be9c3dc048ab 100644
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -549,7 +549,7 @@ int autofs4_wait_release(struct autofs_sb_info *sbi, autofs_wqt_t wait_queue_tok
kfree(wq->name.name);
wq->name.name = NULL; /* Do not wait on this queue */
wq->status = status;
- wake_up_interruptible(&wq->queue);
+ wake_up(&wq->queue);
if (!--wq->wait_ctr)
kfree(wq);
mutex_unlock(&sbi->wq_mutex);
--
2.13.6
On 31/03/18 10:28, Andrei Vagin wrote:
> In "autofs4: use wait_event_killable", wait_event_interruptible() was
> replaced by wait_event_killable(), but in this case we have to use
> wake_up() instead of wake_up_interruptible().
Why do you believe wake_up() is needed rather than wake_up_interruptible()?
Now that I'm thinking about the wake up I'm wondering if this is in fact
what's needed. Rather, I think maybe wake_up_all() is probably the only
one that will actually do what's needed.
There's an individual wait queue for each mount, there can be multiple
waiters for a mount, they all should be woken up when the daemon signals
mount completion.
>
> Cc: Matthew Wilcox <[email protected]>
> Cc: Ian Kent <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: Stephen Rothwell <[email protected]>
> Signed-off-by: Andrei Vagin <[email protected]>
> ---
> fs/autofs4/waitq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> index c160e9b3aa0f..be9c3dc048ab 100644
> --- a/fs/autofs4/waitq.c
> +++ b/fs/autofs4/waitq.c
> @@ -549,7 +549,7 @@ int autofs4_wait_release(struct autofs_sb_info *sbi, autofs_wqt_t wait_queue_tok
> kfree(wq->name.name);
> wq->name.name = NULL; /* Do not wait on this queue */
> wq->status = status;
> - wake_up_interruptible(&wq->queue);
> + wake_up(&wq->queue);
> if (!--wq->wait_ctr)
> kfree(wq);
> mutex_unlock(&sbi->wq_mutex);
>
On 01/04/18 09:31, Ian Kent wrote:
> On 31/03/18 10:28, Andrei Vagin wrote:
>> In "autofs4: use wait_event_killable", wait_event_interruptible() was
>> replaced by wait_event_killable(), but in this case we have to use
>> wake_up() instead of wake_up_interruptible().
>
> Why do you believe wake_up() is needed rather than wake_up_interruptible()?
>
> Now that I'm thinking about the wake up I'm wondering if this is in fact
> what's needed. Rather, I think maybe wake_up_all() is probably the only
> one that will actually do what's needed.
Ok, so that 1 is the number of exclusive waiters.
So what is the difference between the two wake_up calls in this case?
>
> There's an individual wait queue for each mount, there can be multiple
> waiters for a mount, they all should be woken up when the daemon signals
> mount completion.
>
>>
>> Cc: Matthew Wilcox <[email protected]>
>> Cc: Ian Kent <[email protected]>
>> Cc: Andrew Morton <[email protected]>
>> Cc: Stephen Rothwell <[email protected]>
>> Signed-off-by: Andrei Vagin <[email protected]>
>> ---
>> fs/autofs4/waitq.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
>> index c160e9b3aa0f..be9c3dc048ab 100644
>> --- a/fs/autofs4/waitq.c
>> +++ b/fs/autofs4/waitq.c
>> @@ -549,7 +549,7 @@ int autofs4_wait_release(struct autofs_sb_info *sbi, autofs_wqt_t wait_queue_tok
>> kfree(wq->name.name);
>> wq->name.name = NULL; /* Do not wait on this queue */
>> wq->status = status;
>> - wake_up_interruptible(&wq->queue);
>> + wake_up(&wq->queue);
>> if (!--wq->wait_ctr)
>> kfree(wq);
>> mutex_unlock(&sbi->wq_mutex);
>>
>
On Sun, Apr 01, 2018 at 10:01:41AM +0800, Ian Kent wrote:
> On 01/04/18 09:31, Ian Kent wrote:
> > On 31/03/18 10:28, Andrei Vagin wrote:
> >> In "autofs4: use wait_event_killable", wait_event_interruptible() was
> >> replaced by wait_event_killable(), but in this case we have to use
> >> wake_up() instead of wake_up_interruptible().
> >
> > Why do you believe wake_up() is needed rather than wake_up_interruptible()?
> >
> > Now that I'm thinking about the wake up I'm wondering if this is in fact
> > what's needed. Rather, I think maybe wake_up_all() is probably the only
> > one that will actually do what's needed.
>
> Ok, so that 1 is the number of exclusive waiters.
> So what is the difference between the two wake_up calls in this case?
In CRIU, we have the autofs test:
https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/autofs.c
We run CRIU tests on the linux-next kernels and a few days ago this test
started to fail, actually it hangs up.
I found that wake_up_interruptible() doesn't wake up a thread, which is
waiting.
try_to_wake_up() has the argument "state", it is the mask of task states
that can be woken.
For wake_up_interruptible(), state is TASK_INTERRUPTIBLE.
For wake_up(). state is TASK_NORMAL (TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
If we use wait_event_killable(), the task sleeps in the TASK_KILLABLE
state, so wake_up_interruptible() isn't suitable in this case.
#define TASK_KILLABLE (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
I checked that our test passes with this patch. I mean that we had a
real problem and we checked that it is fixed by this patch.
Thanks,
Andrei
>
> >
> > There's an individual wait queue for each mount, there can be multiple
> > waiters for a mount, they all should be woken up when the daemon signals
> > mount completion.
> >
> >>
> >> Cc: Matthew Wilcox <[email protected]>
> >> Cc: Ian Kent <[email protected]>
> >> Cc: Andrew Morton <[email protected]>
> >> Cc: Stephen Rothwell <[email protected]>
> >> Signed-off-by: Andrei Vagin <[email protected]>
> >> ---
> >> fs/autofs4/waitq.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
> >> index c160e9b3aa0f..be9c3dc048ab 100644
> >> --- a/fs/autofs4/waitq.c
> >> +++ b/fs/autofs4/waitq.c
> >> @@ -549,7 +549,7 @@ int autofs4_wait_release(struct autofs_sb_info *sbi, autofs_wqt_t wait_queue_tok
> >> kfree(wq->name.name);
> >> wq->name.name = NULL; /* Do not wait on this queue */
> >> wq->status = status;
> >> - wake_up_interruptible(&wq->queue);
> >> + wake_up(&wq->queue);
> >> if (!--wq->wait_ctr)
> >> kfree(wq);
> >> mutex_unlock(&sbi->wq_mutex);
> >>
> >
>
On 01/04/18 14:21, Andrei Vagin wrote:
> On Sun, Apr 01, 2018 at 10:01:41AM +0800, Ian Kent wrote:
>> On 01/04/18 09:31, Ian Kent wrote:
>>> On 31/03/18 10:28, Andrei Vagin wrote:
>>>> In "autofs4: use wait_event_killable", wait_event_interruptible() was
>>>> replaced by wait_event_killable(), but in this case we have to use
>>>> wake_up() instead of wake_up_interruptible().
>>>
>>> Why do you believe wake_up() is needed rather than wake_up_interruptible()?
>>>
>>> Now that I'm thinking about the wake up I'm wondering if this is in fact
>>> what's needed. Rather, I think maybe wake_up_all() is probably the only
>>> one that will actually do what's needed.
>>
>> Ok, so that 1 is the number of exclusive waiters.
>> So what is the difference between the two wake_up calls in this case?
>
> In CRIU, we have the autofs test:
> https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/autofs.c
>
> We run CRIU tests on the linux-next kernels and a few days ago this test
> started to fail, actually it hangs up.
>
> I found that wake_up_interruptible() doesn't wake up a thread, which is
> waiting.
>
> try_to_wake_up() has the argument "state", it is the mask of task states
> that can be woken.
>
> For wake_up_interruptible(), state is TASK_INTERRUPTIBLE.
> For wake_up(). state is TASK_NORMAL (TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
>
> If we use wait_event_killable(), the task sleeps in the TASK_KILLABLE
> state, so wake_up_interruptible() isn't suitable in this case.
>
> #define TASK_KILLABLE (TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
>
> I checked that our test passes with this patch. I mean that we had a
> real problem and we checked that it is fixed by this patch.
Ahh, I see, wake_up_*() functions do just what they say, they skip
TASK_UNINTERRUPTIBLE tasks.
Now it makes sense.
Acked-by: Ian Kent <[email protected]>
Andrew could you a take this patch as well please.
>
> Thanks,
> Andrei
>
>>
>>>
>>> There's an individual wait queue for each mount, there can be multiple
>>> waiters for a mount, they all should be woken up when the daemon signals
>>> mount completion.
>>>
>>>>
>>>> Cc: Matthew Wilcox <[email protected]>
>>>> Cc: Ian Kent <[email protected]>
>>>> Cc: Andrew Morton <[email protected]>
>>>> Cc: Stephen Rothwell <[email protected]>
>>>> Signed-off-by: Andrei Vagin <[email protected]>
>>>> ---
>>>> fs/autofs4/waitq.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
>>>> index c160e9b3aa0f..be9c3dc048ab 100644
>>>> --- a/fs/autofs4/waitq.c
>>>> +++ b/fs/autofs4/waitq.c
>>>> @@ -549,7 +549,7 @@ int autofs4_wait_release(struct autofs_sb_info *sbi, autofs_wqt_t wait_queue_tok
>>>> kfree(wq->name.name);
>>>> wq->name.name = NULL; /* Do not wait on this queue */
>>>> wq->status = status;
>>>> - wake_up_interruptible(&wq->queue);
>>>> + wake_up(&wq->queue);
>>>> if (!--wq->wait_ctr)
>>>> kfree(wq);
>>>> mutex_unlock(&sbi->wq_mutex);
>>>>
>>>
>>