| 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
| ||
|
Date: Sat, 19 Dec 2009 15:02:06 +0300 From: Nikolai ZHUBR <zhubr@...l.ru> To: linux-kernel@...r.kernel.org Subject: epoll'ing tcp sockets for reading Hello people, I have a question about epoll'ing tcp sockets. Is it possible (with epoll or some other good method) to get userspace notified not only of the fact that some data has become available for the socket, but also of the respective _size_ available for reading connected with this exact event? Yes, read'ing until EAGAIN or using FIONREAD would provide this sort of information, but there is a problem. In case of subsequent continuous data arrival, an application could get stuck reading data for one socket infinitely (after epoll return, just before the next epoll), unless it implements some kind of artifical safety measures. To my understanding, EPOLLONESHOT does not suffice here, because it only "fixes" the epoll'ing part but not the read'ing part, whereas _both_ epoll'ing and read'ing appear to be responsible. Therefore, "event atomicity" is lost anyway. Or am I wrong? (Please CC me, I'm not subscribed) Thank you! Nikolai ZHUBR -- 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