From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>, linuxppc-dev@lists.ozlabs.org
Subject: more POLL... fun
Date: Fri, 4 Dec 2015 06:38:25 +0000 [thread overview]
Message-ID: <20151204063825.GH22011@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20151130030427.GY22011@ZenIV.linux.org.uk>
On cross-builds the __poll_t annotations had caught something interesting:
void spufs_mfc_callback(struct spu *spu)
{
....
mask = 0;
if (free_elements & 0xffff)
mask |= POLLOUT;
if (tagstatus & ctx->tagwait)
mask |= POLLIN;
kill_fasync(&ctx->mfc_fasync, SIGIO, mask);
....
}
That's arch/powerpc/platforms/cell/spufs/file.c. WTF is kill_fasync()
getting as the last argument here? Valid values are
#define POLL_IN (__SI_POLL|1) /* data input available */
#define POLL_OUT (__SI_POLL|2) /* output buffers available */
#define POLL_MSG (__SI_POLL|3) /* input message available */
#define POLL_ERR (__SI_POLL|4) /* i/o error */
#define POLL_PRI (__SI_POLL|5) /* high priority input available */
#define POLL_HUP (__SI_POLL|6) /* device disconnected */
Use of POLLIN, POLLOUT, etc. here is wrong - kill_fasync() will step into
BUG_ON((reason & __SI_MASK) != __SI_POLL);
in send_sigio_to_task(). Other two callers of kill_fasync() in that file
are trivially fixed by switching to POLL_IN and POLL_OUT; with this one
I've no idea what had been intended.
What's more, I really wonder if it had _ever_ been tested - these kill_fasync()
calls had been introduced in
commit 8b3d6663c6217e4f50cc3720935a96da9b984117
Author: Arnd Bergmann <arnd@arndb.de>
Date: Tue Nov 15 15:53:52 2005 -0500
[PATCH] spufs: cooperative scheduler support
more than 5 years after that BUG_ON() had been added - it goes back to
+ /* Make sure we are called with one of the POLL_*
+ reasons, otherwise we could leak kernel stack into
+ userspace. */
+ if ((reason & __SI_MASK) != __SI_POLL)
+ BUG();
in 2.3.99pre-10-3, on May 25 2000.
What the hell am I missing here? Has that code been DOA and never used by
anyone in all the decade it had been in mainline?
next prev parent reply other threads:[~2015-12-04 6:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-27 5:00 ->poll() instances shouldn't be indefinitely blocking Al Viro
2015-11-27 15:18 ` Mauro Carvalho Chehab
2015-11-27 17:49 ` Linus Torvalds
2015-11-30 3:04 ` Al Viro
2015-12-04 6:38 ` Al Viro [this message]
2015-12-04 9:16 ` more POLL... fun Arnd Bergmann
2015-12-04 15:21 ` Al Viro
2015-12-04 17:13 ` Arnd Bergmann
2015-12-04 17:30 ` Al Viro
2015-12-04 17:34 ` Arnd Bergmann
2015-12-06 23:58 ` Michael Ellerman
2017-02-16 5:59 ` Michael Ellerman
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=20151204063825.GH22011@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=arnd@arndb.de \
--cc=linuxppc-dev@lists.ozlabs.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.