Message-id: <4552D7A6.4060505@cosmosbay.com>
Date:	Thu, 09 Nov 2006 08:24:22 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Davide Libenzi <davidel@...ilserver.org>
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.

Davide Libenzi a écrit :
> 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 my particular epoll application, the producer is tcp stack, and I have one 
consumer. If an network event is lost in the EFAULT handling, its lost 
forever. In any case, my application do provide a correct user area, so this 
problem is only theorical.

> 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. 

Please dont slow the hot path for a basically "User Error". It's already 
tested in the transfert function, with two conditional branches for each 
transfered event.

> 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.

Yes, but this particular patch was a followup on own kevent Andrew patch.

I have a bunch of patches for epoll I will send to you :)

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

Powered by blists - more mailing lists