From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Piggin <npiggin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Mel Gorman <mgorman@techsingularity.net>, Jan Kara <jack@suse.cz>,
Davidlohr Bueso <dave@stgolabs.net>,
Andi Kleen <ak@linux.intel.com>,
Lukas Czerner <lczerner@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: wait_on_page_bit_common(TASK_KILLABLE, EXCLUSIVE) can miss wakeup?
Date: Wed, 24 Jun 2020 18:43:20 +0200 [thread overview]
Message-ID: <20200624164319.GA12203@redhat.com> (raw)
In-Reply-To: <CAHk-=wjqnKdrjZx0kO+f1vyFQFcb-HZsbHFw6_jAeuQmNsTsbQ@mail.gmail.com>
On 06/24, Linus Torvalds wrote:
>
> That said, I'm not entirely happy with your patch.
Neither me,
> The real problem, I feel, is that
>
> if (likely(bit_is_set))
> io_schedule();
>
> anti-pattern. Without that, we wouldn't have the bug.
>
> Normally, we'd be TASK_RUNNING in this sequence, but because we might
> skip io_schedule(), we can still be in a "sleeping" state here and be
> "woken up" between that bit setting and the signal check.
Ah.
And now it _seems_ to me that even if io_schedule() is called
try_to_wake_up() can "falsely" succed if signal_pending_state() is true,
even if __schedule() won't block in this case.
But I am sure I missed something else. I spent to much time reading the
random code paths today, I'll return tomorrow.
Oleg.
prev parent reply other threads:[~2020-06-24 16:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-24 16:11 wait_on_page_bit_common(TASK_KILLABLE, EXCLUSIVE) can miss wakeup? Oleg Nesterov
2020-06-24 16:20 ` Oleg Nesterov
2020-06-24 16:36 ` Linus Torvalds
2020-06-26 15:43 ` Peter Zijlstra
2020-06-28 5:39 ` Linus Torvalds
2020-06-28 13:18 ` Peter Zijlstra
2020-06-29 3:28 ` Nicholas Piggin
2020-06-29 13:16 ` Nicholas Piggin
2020-06-29 16:36 ` Linus Torvalds
2020-06-30 2:12 ` Nicholas Piggin
2020-06-29 14:02 ` Oleg Nesterov
2020-06-30 2:08 ` Nicholas Piggin
2020-06-30 6:17 ` Oleg Nesterov
2020-06-30 9:08 ` Nicholas Piggin
2020-06-30 10:53 ` Oleg Nesterov
2020-06-30 11:36 ` Oleg Nesterov
2020-06-30 11:50 ` Oleg Nesterov
2020-06-30 18:02 ` Linus Torvalds
2020-06-30 18:29 ` Oleg Nesterov
2020-06-30 18:57 ` Linus Torvalds
2020-06-29 15:13 ` Oleg Nesterov
2020-06-24 16:22 ` Linus Torvalds
2020-06-24 16:43 ` Oleg Nesterov [this message]
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=20200624164319.GA12203@redhat.com \
--to=oleg@redhat.com \
--cc=ak@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=jack@suse.cz \
--cc=lczerner@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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.