linux-kernel - Re: [RFC PATCH] poll(): add poll_wait_set

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:	Wed, 6 Oct 2010 12:41:44 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Hellwig <hch@....de>, Li Zefan <lizf@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Johannes Berg <johannes.berg@...el.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Tom Zanussi <tzanussi@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andi Kleen <andi@...stfloor.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>
Subject: Re: [RFC PATCH] poll(): add poll_wait_set_exclusive()

On Wed, Oct 6, 2010 at 12:04 PM, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com> wrote:
>
> You are right. My approach breaks the select/poll semantics. This is why I'm
> asking for input if we want to solve the more general problem. For the moment,
> the poll_wait_set_exclusive() solution was only meant to be used for debugfs
> kernel pseudo-files, which fall out of the POSIX scope.

The thing is, I don't think "that file isn't mentioned by POSIX" is a
valid excuse for having different semantics for any particular file.

So no, I don't think it's acceptable to say that certain files just
act differently wrt "poll".

> Maybe what I am trying to do is too far from the poll() semantic and does not
> apply in the general case, but I clearly see the need, at least in the use-case
> detailed below, to wake up only one thread at a time, whether we call this
> "poll" or something else. One way to make it available more generally might be
> to add a new open() flag and require that all open() of a given file should use
> the flag to provide the "wakeup only one thread" behavior.

I think that would be a better interface, but still sucky and badly
designed. Why? Because the obvious case where you might want to have
the whole "only wake up a single thread" is actually for sockets, so
having an open-time flag is just insane.

Making it be an file status flag (and then use fcntl F_[GS]ETFL on it)
might work. At the same time, I have the suspicion that it would be
much nicer to embed it into the "requested events" field to poll, and
simply add a "exclusive read" poll event (POLLINEX or whatever).
Because it's really the "poll()" function itself that says "I promise
that if you return a readable file descriptor, I will read everything
from it" - it's really an attribute local to the "poll()", not to the
file descriptor.

Regardless, I really think that for anything like this to make sense,
it needs way more than a single use case. So you'd really want to get
some web server developers excited or something like that. Over the
years we have learnt that one-off use cases are worthless.

Also, doesn't eventpoll already support exclusive polling? I dunno.
Davide might be interested in the discussion regardless.

                     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/