linux-kernel - Re: [take23 0/5] kevent: Generic event handling mechanism.

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, 8 Nov 2006 15:56:28 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Eric Dumazet <dada1@...mosbay.com>
cc:	Andrew Morton <akpm@...l.org>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	David Miller <davem@...emloft.net>,
	Ulrich Drepper <drepper@...hat.com>,
	netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>,
	Johann Borck <johann.borck@...sedata.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: [take23 0/5] kevent: Generic event handling mechanism.

On Thu, 9 Nov 2006, Eric Dumazet wrote:

> Davide Libenzi a écrit :
> > 
> > I don't care about both ways, but sys_poll() does the same thing epoll does
> > right now, so I would not change epoll behaviour.
> > 
> 
> Sure poll() cannot return a partial count, since its return value is :
> 
> On success, a positive number is returned, where the number returned is
>        the  number  of structures which have non-zero revents fields (in other
>        words, those descriptors with events or errors reported).
> 
> poll() is non destructive (it doesnt change any state into kernel). Returning
> EFAULT in case of an error in the very last bit of user area is mandatory.
> 
> On the contrary :
> 
> epoll_wait() does return a count of transfered events, and update some state
> in kernel (it consume Edge Trigered events : They can be lost forever if not
> reported to user)
> 
> So epoll_wait() is much more like read(), that also updates file state in
> kernel (current file position)

Lost forever means? If there are more processes watching some fd 
(external events), they all get their own copy of the events in their own 
private epoll fd. It's not that we "steal" things out of the kernel, is 
not a 1:1 producer/consumer thing (one producer, 1 queue). It's one 
producer, broadcast to all listeners (consumers) thing. The only case 
where it'd matter is in the case of multiple threads sharing the same 
epoll fd.
In general, I'd be more for having the userspace get his own SEGFAULT 
instead of letting it go with broken parameters. If I'm coding userspace, 
and I'm doing something wrong, I like the kernel to let me know, instead 
of trying to fix things for me.
Also, epoll can easily be fixed (add a param to ep_reinject_items() to 
re-inject items in case of error/EFAULT) to leave events in the ready-list 
and let the EFAULT emerge. 
Anyone else has opinions about this?

PS: Next time it'd be great if you Cc: me when posting epoll patches, so 
    you avoid Andrew the job of doing it.

- Davide