linux-kernel - Re: Fundamental race condition in wait_event_interruptible

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]

Date:   Mon, 9 Dec 2019 10:03:11 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Miklos Szeredi <miklos@...redi.hu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Felipe Balbi <balbi@...nel.org>
Subject: Re: Fundamental race condition in wait_event_interruptible_exclusive()
 ?

On Mon, Dec 9, 2019 at 9:38 AM Oleg Nesterov <oleg@...hat.com> wrote:
>
> > because we've added ourselves as an exclusive writer to the
> > queue. So it _says_ it was interrupted, not woken up, and the wait got
> > cancelled, but because we were an exclusive waiter, we might be the
> > _only_ thing that got woken up,
>
> And that is why ___wait_event() always checks the condition after
> prepare_to_wait_event(), whatever it returns.

Ack. I misread the code, and you're right - if we've been woken up,
the condition is supposed to be true, and we never actually return
-ERESTARTSYS.

So the situation of "got woken but returned error, and lost wakeup"
won't actually ever happen.

Good.

So yeah, I can do what I wanted to do, and it should all work.

I never even tested it, because I was getting fairly anal about
possible races in the pipe code by then.

               Linus