All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Vagin <avagin@virtuozzo.com>
To: Ian Kent <raven@themaw.net>
Cc: Andrei Vagin <avagin@openvz.org>,
	autofs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH] autofs4: use wake_up() instead of wake_up_interruptible
Date: Sat, 31 Mar 2018 23:21:18 -0700	[thread overview]
Message-ID: <20180401062117.GA27067@outlook.office365.com> (raw)
In-Reply-To: <8d578e49-c1a0-a38d-3b91-f0a07de0089b@themaw.net>

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 <mawilcox@microsoft.com>
> >> Cc: Ian Kent <raven@themaw.net>
> >> Cc: Andrew Morton <akpm@linux-foundation.org>
> >> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> >> Signed-off-by: Andrei Vagin <avagin@openvz.org>
> >> ---
> >>  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);
> >>
> > 
> 

  reply	other threads:[~2018-04-01  6:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-31  2:28 [PATCH] autofs4: use wake_up() instead of wake_up_interruptible Andrei Vagin
2018-04-01  1:31 ` Ian Kent
2018-04-01  2:01   ` Ian Kent
2018-04-01  6:21     ` Andrei Vagin [this message]
2018-04-02 23:39       ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180401062117.GA27067@outlook.office365.com \
    --to=avagin@virtuozzo.com \
    --cc=akpm@linux-foundation.org \
    --cc=autofs@vger.kernel.org \
    --cc=avagin@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=raven@themaw.net \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.