From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030225 Description of problem: In fact there are two problems: 1. TCP connection becomes unusable if too many read AIO requests are posted on the socket (after some time the peer cannot transmit data). 2. Posting of too many write AIO requests on UDP socket leads to loss of datagrams. Of course, they may be lost because this is UDP, but when I discovered the problem first I tried sending/receiving on different stations and observed (using tcpdump) that packets are not sent at all! The attached test reproduces both problems on the one host. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: First problem: 1. Create two connected stream sockets. 2. Post a lot of read request on one of them. 3. Try to satisfy all requests sending data via second socket. 4. After some time sending blocks (before we've satisfied all requests). Second problem: 1. Create two connected datagram sockets. 2. Post lot of write requests on one of them. 3. Some datagram are not received by the peer and sniffer shows that they do not appear in the network. Additional info:
Created attachment 119431 [details] Test to reproduce the problem See usage and comments in the file.
Can you explain what exactly is unexpected on this? Say with: rd inet stream 1000 arguments, you get Cannot satisfy write AIO request; errno 11 which is to be expected when you use non-blocking writes.
If blocking request is used, it blocks forever, non-blocking call is used only to print proper error message. It should not happen if the peer reads data from the connection (and it should read, because not completed read requests are pending yet).
When you use non-blocking sends, when you get EAGAIN, you stop sending further writes. If I use 0 as last argument to send/recv, it works just fine: ./aiotest rd inet stream 10000 10000 read requests and 0 write requests are posted Passed
For me it sometimes passes and sometimes blocks (I mean with zero send flags). Try "rdwr inet stream 1000", please. It happens much more often when both read and write requests are used.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.