linux-kernel - Re[3]: epoll'ing tcp sockets for reading

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:	Sun, 20 Dec 2009 07:54:09 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Nikolai ZHUBR <zhubr@...l.ru>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re[3]: epoll'ing tcp sockets for reading

On Sun, 20 Dec 2009, Nikolai ZHUBR wrote:

> Sunday, December 20, 2009, 1:56:22 AM, Davide Libenzi wrote:
> [trim]
> > The kernel cannot make decisions based on something whose knowledge is 
> > userspace bound.
> I didn't mean that. I just meant it would be usefull to let the caller
> of epoll know also the size of data related to specific EPOLLIN event in
> some "atomic" manner immediately, because the kernel probably knows this
> size already.
> The same thing can approximately be "emulated" by requesting FIOREAD for
> all EPOLLIN-ready sockets just after epoll returns, before any other work.
> It just would look not very elegant IMHO.

No such a thing of "atomic matter", since by the time you read the event, 
more data might have come. It's just flawed, you see that?



> > What you define as "abstract/imprecise/overcomplicated" are simply 
> > decisions that you, as implementor of the upper layer protocol, have to 
> > take in order to implement your userspace code.
> > And I, personally, see nothing even close to be defined complicated in 
> > such code.
> > Whenever you're asking for an abstraction/API to implement a kind 
> > of software which exist in large quantities on a system, you've got to ask 
> > yourself how relevant such abstraction is at the end, if all the existing 
> > software have done w/out it.
> Ok, maybe that's what I should have asked at the first place. What would
> you recommend as a reference implementation showing clean, efficient,
> fail-safe usage of epoll with sockets?
> Actually I've been googling for about 2 weeks to find some, but the results
> are rather scarce and dubious.

My reference was not epoll in particular, but more in general all the 
network/server software that have been written using select/poll and the 
current POSIX APIs, w/out the need of knowing how much data there was on 
the link.



- Davide


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