linux-kernel - Re: [git pull] vfs.git: poll annotations

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: <20180131044620.GF29051@ZenIV.linux.org.uk>
Date:   Wed, 31 Jan 2018 04:46:20 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [git pull] vfs.git: poll annotations

On Tue, Jan 30, 2018 at 07:19:19PM -0800, Linus Torvalds wrote:
> On Tue, Jan 30, 2018 at 7:13 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > As for the place for mangle/demangle... where would you prefer them?
> 
> If we can make gcc generate ok code for the generic case and not need
> any arch-specific ones, why not just do in <linux/poll.h>?

Umm...  I'll try and see how well does that work.

> (And I guess POLLIN/OUT/ERR are standard, so it's only a couple that
> need to have potential help translating? That would make the helper
> inline smaller and simpler)

To quote a mail from last July:

||             common  bfin,frv,m68k,mips       xtensa  sparc
||WRNORM bit      8       2                       2       2
||WRBAND bit      9       8                       8       8
||MSG bit         10      10                      10      9
||REMOVE bit      12      12                      11      10
||RDHUP bit       13      13                      13      11
||
||Now, POLLREMOVE doesn't have EPOLL... equivalent, but others
||do.  As the result, blackfin, frv, m68k, mips and xtensa have
||EPOLLWRNORM matching POLLWRBAND and EPOLLWRBAND not matching
||anything.  sparc has EPOLLWRNORM matching POLLWRBAND, EPOLLWRBAND
||matching POLLMSG (and never triggered), EPOLLMSG matching POLLREMOVE
||(and also never triggered) and EPOLLRDHUP not matching anything.
||
||I don't believe that anything tries to use EPOLLMSG; EPOLLWRBAND
||and EPOLLWRNORM might be used (even though our manpage doesn't
||document either).  EPOLLRDHUP _is_ documented and flat-out does
||not work on sparc; the only way to catch POLLRDHUP via epoll
||there is to give it a value that is not any of EPOLL... constants.
||Hell knows if anything tries to do it there...

MSG and REMOVE are never triggered, so it's all down to {WR{NORM,BAND},RDHUP}.

Logics for mangle should be uniform - lower 8 bits left as is,
EPOLLWRBAND -> POLLWRBAND, EPOLLWRNORM -> POLLWRNORM, EPOLLRDHUP -> POLLRDHUP.

For demangle it's
if POLLOUT != POLLWRNORM
	pass as is
else
	lower 8 bits left as-is,
	if POLLOUT
		add EPOLLWRNORM
	POLLWRBAND -> EPOLLWRBAND
	POLLRDHUP -> EPOLLRDHUP

Frankly, it's a bloody mess - we either shouldn't have bothered with separate
POLLRDNORM and POLLWRNORM at all (they should be equivalent to POLLIN and POLLOUT
resp.) or kept them separate on all architectures.  What's more, we don't have
only one instance of POLLRDNORM that would not be a part of POLLIN | POLLRDNORM | ...
(modulo reordering).  Its definition, that is.  We do have a few instances of
->poll() that raise POLLIN without POLLRDNORM, but AFAICS they have only one
thing in common - "forgot to add POLLRDNORM or hadn't heard of it".  The set is
pretty much random...

It started in 2.1.23pre1; looks like the original braindamage came from SunOS compat
(in 1.3.93) and got propagated into generic when poll(2) was implemented.  Probably
we should've kept alpha and i386 POLL... definitions same as sparc ones...  Anyway,
it's at least 20 years too late for that.