All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>, Neil Brown <neilb@suse.de>,
	Michael Shaver <jmshaver@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: Avoid that __wait_on_bit_lock() hangs
Date: Mon, 8 Aug 2016 18:20:38 +0200	[thread overview]
Message-ID: <20160808162038.GA25927@redhat.com> (raw)
In-Reply-To: <4091e252-18d9-1795-de63-9fbc678aa6b1@acm.org>

On 08/08, Bart Van Assche wrote:
>
> This is the sequence of which I think that it leads to the missed wakeup:
>
> Task 1                    Task 2                    Task 3                    Task 4
>
> lock_page()
>  ...
>                           lock_page_killable()
>                            __lock_page_killable()
>                             __wait_on_bit_lock()
>                              bit_wait_io()
>                               io_schedule()
>                                ...
>                                                                               lock_page()
>                                                                                __lock_page()
>                                                                                 __wait_on_bit_lock()
>                                                                                  bit_wait_io()
>                                                                                   io_schedule()
>                                                                                    ...
>
>
>                                                     (signal delivery to task 2)
>                                                     try_to_wake_up(task2, ..., ...)
>                                                     (try_to_wake_up() returns 1)
>
> unlock_page()
>  wake_up_page()
>   __wake_up_bit()
>    __wake_up(wq, TASK_NORMAL, 1, &key)
>     __wake_up_common(wq, mode=TASK_NORMAL, nr_exclusive=1, 0, key)
>      wake_bit_function()
>       autoremove_wake_function()
>        default_wake_function()
>         try_to_wake_up() <- skips task 2 because task 3 already changed
>                             the task state of task 2
>        (autoremove_wake_function() does not do
>         list_del_init(&wait->task_list))

Yes.

But since it skips task2, __wake_up_common() doesn't decrement nr_exclusive,
doesn't stop. It continues the list_for_each_entry_safe() loop, and finds the
sleeping task4, and wakes it up,

>                               bit_wait_io() returns -EINTR
>                              abort_exclusive_wait() is called by __wait_on_bit_lock()
>
>
> In the above sequence task 1 does not remove task 2 from the waitqueue
> because task 3 had already woken up task 2. The result is that when task 2
> calls abort_exclusive_wait() that task 2 is still on the waitqueue.

Yes, but this is fine,

> With the
> current implementation of abort_exclusive_wait() in the above scenario task
> 4 is not woken up although it should be woken up.

See above, it must be already woken by __wake_up_common().



So far _I think_ that the bug is somewhere else... Say, someone clears
PG_locked without wake_up(). Then SIGKILL sent to the task sleeping in
sys_read() "adds" the necessary wakeup...

Do you use external modules during the testing?

Oleg.

  reply	other threads:[~2016-08-08 16:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-03 16:35 [PATCH] sched: Avoid that __wait_on_bit_lock() hangs Bart Van Assche
2016-08-03 18:11 ` Peter Zijlstra
2016-08-03 18:56   ` Bart Van Assche
2016-08-03 21:30     ` Oleg Nesterov
2016-08-03 21:51       ` Bart Van Assche
2016-08-04 14:09         ` Peter Zijlstra
2016-08-04 14:31           ` Bart Van Assche
2016-08-05 17:41           ` Bart Van Assche
2016-08-08 10:22             ` Peter Zijlstra
2016-08-08 14:38               ` Bart Van Assche
2016-08-08 16:20                 ` Oleg Nesterov [this message]
2016-08-08 18:31                   ` Bart Van Assche
2016-08-09 17:14                     ` Oleg Nesterov
2016-08-09 18:48                       ` Bart Van Assche
2016-08-09 23:10                         ` Bart Van Assche
2016-08-10 10:45                         ` Oleg Nesterov
2016-08-10 16:01                           ` Bart Van Assche
2016-08-10 16:27                             ` Oleg Nesterov
2016-08-10 19:58                           ` Bart Van Assche
2016-08-11 17:36                             ` Oleg Nesterov
2016-08-12 16:16                               ` Oleg Nesterov
2016-08-12 16:27                                 ` Bart Van Assche
2016-08-12 22:47                                 ` Bart Van Assche
2016-08-13 16:32                                   ` Oleg Nesterov
2016-08-15 23:39                                     ` Bart Van Assche
2016-08-16 13:06                                       ` Oleg Nesterov
2016-08-16 16:54                                         ` Bart Van Assche
2016-08-17 17:30                                           ` Oleg Nesterov
2016-08-13 17:07                                   ` Oleg Nesterov
2016-08-09 23:56                   ` Bart Van Assche
2016-08-10 10:57                     ` Oleg Nesterov
2016-08-10 11:03                       ` Peter Zijlstra
2016-08-04  0:05       ` Bart Van Assche

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=20160808162038.GA25927@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bvanassche@acm.org \
    --cc=hannes@cmpxchg.org \
    --cc=jmshaver@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=neilb@suse.de \
    --cc=peterz@infradead.org \
    /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.