Bug 169572 - Posting of too many AIO requests on the one socket leads to unexpected behaivour
Posting of too many AIO requests on the one socket leads to unexpected behaivour
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-09-29 15:07 EDT by Elena Vengerova
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-22 12:41:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test to reproduce the problem (6.11 KB, text/plain)
2005-09-29 15:09 EDT, Elena Vengerova
no flags Details

  None (edit)
Description Elena Vengerova 2005-09-29 15:07:11 EDT
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:

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:
Comment 1 Elena Vengerova 2005-09-29 15:09:33 EDT
Created attachment 119431 [details]
Test to reproduce the problem

See usage and comments in the file.
Comment 2 Jakub Jelinek 2005-09-30 03:41:51 EDT
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.
Comment 3 Elena Vengerova 2005-09-30 04:05:15 EDT
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).
Comment 4 Jakub Jelinek 2005-09-30 06:19:38 EDT
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
Comment 5 Elena Vengerova 2005-09-30 07:29:45 EDT
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.
Comment 6 Christian Iseli 2007-01-22 06:24:15 EST
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 ?


Note You need to log in before you can comment on or make changes to this bug.