linux-kernel - Re: [PATCH 2/2] poll: allow f

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] [day] [month] [year] [list]

Message-ID: <20080826202250.GA16072@elte.hu>
Date:	Tue, 26 Aug 2008 22:22:50 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Tejun Heo <htejun@...il.com>, Al Viro <viro@...IV.linux.org.uk>,
	hch@...radead.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Eric Van Hensbergen <ericvh@...il.com>,
	Ron Minnich <rminnich@...dia.gov>,
	v9fs-developer@...ts.sourceforge.net
Subject: Re: [PATCH 2/2] poll: allow f_op->poll to sleep

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, 26 Aug 2008, Tejun Heo wrote:
> > 
> > This patch converts poll/select to use custom wake up function and use
> > separate triggered variable to synchronize against wake up events.
> > The only added overhead is an extra function call during wake up and
> > negligible.
> 
> I don't really see the point.
> 
> poll() isn't allowed to sleep for many reasons. Some are technical. 
> But the most obvious one is that a sleeping "poll()" is totally 
> against the whole point of polling in the first place!
> 
> So is there some big conceptual reason to change how poll() has always 
> worked?

i think the point is to replace potentially fragile atomic code with 
less restricted 'potentially sleeping' code.

For example a GFP_KERNEL allocation will not sleep in 99% of the cases, 
and if it sleeps we are under such memory pressure that we dont really 
care all that much whether we happen to sleep in poll() or in the next 
userspace pagefault.

The whole ->poll() handler model would be less restricted. I dont think
that's a bad idea - all our atomic contexts suffer from programmability
restrictions, and people are trying to get away from them.

Plus it seems to enable FUSE some more as well - and FUSE has been 
spearheading a lot of filesystem development lately. FUSE is IMO the 
useful form of microkernels - a fast prototyping platform with a very 
friendly user-space programming and debugging interface. (and the fact 
that FUSE based filesystems can be packaged up and distributed a lot 
easier than kernel changes is an argument in favor of FUSE as well)

	Ingo
--
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/