linux-kernel - Re: (more) epoll troubles

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]

Message-ID: <48BC2746.1090006@shaw.ca>
Date:	Mon, 01 Sep 2008 11:32:54 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Michael Noisternig <mnoist@...y.sbg.ac.at>
CC:	linux-kernel@...r.kernel.org
Subject: Re: (more) epoll troubles

Robert Hancock wrote:
> Michael Noisternig wrote:
>> Hello,
>>
>> and sorry again if this is the wrong place to ask (again, please hint 
>> to me to an appropriate place to ask in that case).
>>
>> After experimenting with epoll edge-triggered mode I am clueless why 
>> on a few occassions I seem to not get any input notification despite 
>> data is available.
>>
>> In detail: I have set up sockets with epoll events 
>> EPOLLET|EPOLLRDHUP|EPOLLIN. When I get EPOLLIN for a socket, I read() 
>> as long as I get what I asked for, i.e. whenever read() returns either 
>> EAGAIN or less data than I asked for I take this as indication that I 
>> must wait for another EPOLLIN notification. However, this does not 
>> seem to work always.
>>
>> Here is some log from my program:
>>
>> 0x9e6b8a8: read not avail (1460/2048 read)
>> i.e. tried to read 2048 bytes, got 1460 -> assume must wait for 
>> EPOLLIN for more data to read
>> (note that the fd is always in the epoll set with 
>> EPOLLET|EPOLLRDHUP|EPOLLIN)
> 
> It would likely be better to always continue trying to read until EAGAIN 
> is returned, even if the read returned less than the requested amount, 
> as implied here:
> 
> http://linux.die.net/man/7/epoll
> 
> "The function do_use_fd() uses the new ready file descriptor until 
> EAGAIN is returned by either read(2) or write(2). An event driven state 
> machine application should, after having received EAGAIN, record its 
> current state so that at the next call to do_use_fd() it will continue 
> to read(2) or write(2) from where it stopped before. "

Though, this is somewhat contradicted by the FAQ section:

"the condition that the read/write I/O space is exhausted can be 
detected by checking the amount of data read/write from/to the target 
file descriptor. For example, if you call read(2) by asking to read a 
certain amount of data and read(2) returns a lower number of bytes, you 
can be sure to have exhausted the read I/O space for such file descriptor."
--
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/