Bug 169572 - Posting of too many AIO requests on the one socket leads to unexpected behaivour
Summary: Posting of too many AIO requests on the one socket leads to unexpected behaivour
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 4
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-29 19:07 UTC by Elena Vengerova
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-09-22 16:41:18 UTC
Type: ---
Embargoed:


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

Description Elena Vengerova 2005-09-29 19:07:11 UTC
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:

Comment 1 Elena Vengerova 2005-09-29 19:09:33 UTC
Created attachment 119431 [details]
Test to reproduce the problem

See usage and comments in the file.

Comment 2 Jakub Jelinek 2005-09-30 07:41:51 UTC
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 08:05:15 UTC
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 10:19:38 UTC
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


Comment 5 Elena Vengerova 2005-09-30 11:29:45 UTC
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 11:24:15 UTC
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.


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