linux-kernel - Re: [possible bug] missed wakeup in do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=whx9iKutjLY6iRBHg2TTzSDXgrZ0-Uj5sUqhyQZZQ_yRQ@mail.gmail.com>
Date:   Sat, 4 Sep 2021 10:12:09 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [possible bug] missed wakeup in do_sigtimedwait()?

On Sat, Sep 4, 2021 at 9:59 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I agree, that seems like a bug, and your fix seems the trivially correct thing.

Oh, never mind.  Signals are special.

Why?

Because TASK_INTERRUPTIBLE is special, and schedule() will check for
"am I trying to sleep while a signal is pending" and will never
actually sleep.

So you can't have missed wakeups from signals, because this sequence
is perfectly ok, by design:

 - signal comes in and is pending

 - we set TASK_INTERRUPTIBLE

 - we are thinking about something *entirely* different, like looking
at a pipe being emty

 - we schedule()

and the pending signal will just mean that we never go to sleep.

It's designed that way exactly so that people who have interruptible
sleeps don't need to think about signals at all - they can concentrate
on doing their own thing, and then do the "signal_pending()" check at
any point without caring.

This has always been true, I had just swapped out that logic from memory.

             Linus