linux-kernel - Re: [PATCH 5/7] userfaultfd: switch to exclusive wakeup for blocking reads

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 15 Jun 2015 20:41:24 -1000
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	"Huangpeng (Peter)" <peter.huangpeng@...wei.com>,
	Paolo Bonzini <pbonzini@...hat.com>, qemu-devel@...gnu.org,
	Pavel Emelyanov <xemul@...allels.com>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
	Andres Lagar-Cavilla <andreslc@...gle.com>,
	Andy Lutomirski <luto@...capital.net>,
	linux-mm <linux-mm@...ck.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Rik van Riel <riel@...hat.com>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	zhang.zhanghailiang@...wei.com,
	Sanidhya Kashyap <sanidhya.gatech@...il.com>,
	Dave Hansen <dave.hansen@...el.com>,
	Peter Feiner <pfeiner@...gle.com>,
	Mel Gorman <mgorman@...e.de>, KVM list <kvm@...r.kernel.org>
Subject: Re: [PATCH 5/7] userfaultfd: switch to exclusive wakeup for blocking reads

On Mon, Jun 15, 2015 at 12:19 PM, Andrea Arcangeli <aarcange@...hat.com> wrote:
>
> Yes, it would leave the other blocked, how is it different from having
> just 1 reader and it gets killed?

Either is completely wrong. But the read() code can at least see that
"I'm returning early due to a signal, so I'll wake up any other
waiters".

Poll simply *cannot* do that. Because by definition poll always
returns without actually clearing the thing that caused the wakeup.

So for "poll()", using exclusive waits is wrong very much by
definition. For read(), you *can* use exclusive waits correctly, it
just requires you to wake up others if you don't read all the data
(either due to being killed by a signal, or because the read was
incomplete).

> If any qemu thread gets killed the thing is going to be noticeable,
> there's no fault-tolerance-double-thread for anything.

What does qemu have to do with anything?

We don't implement kernel interfaces that are broken, and that can
leave processes blocked when they shouldn't be blocked. We also don't
implement kernel interfaces that only work with one program and then
say "if that program is broken, it's not our problem".

> I'm not saying doing wakeone is easy [...]

Bullshit, Andrea.

That's *exactly* what you said in the commit message for the broken
patch that I complained about. And I quote:

  "Blocking reads can easily use exclusive wakeups. Poll in theory
could too but there's no poll_wait_exclusive in common code yet"

and I pointed out that your commit message was garbage, and that it's
not at all as easy as you claim, and that your patch was broken, and
your description was even more broken.

The whole "poll cannot use exclsive waits" has _nothing_ to do with us
not having "poll_wait_exclusive()". Poll *fundamentally* cannot use
exclusive waits. Your commit message was garbage, and actively
misleading. Don't make excuses.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/