linux-kernel - io_submit delay problems revisited

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-next>] [day] [month] [year] [list]

Date:	Fri, 22 Dec 2006 22:16:06 -0500 (EST)
From:	Patrick Reynolds <reynolds@...duke.edu>
To:	linux-kernel@...r.kernel.org
Subject: io_submit delay problems revisited

I believe that io_submit() blocks when it shouldn't.  I have read the two
recent LKML threads on the subject.

My computer is a Thinkpad X60: Core Duo 1.83 with a SATA hard disk and
1.5GB of RAM.  I'm running a plain-vanilla 2.6.19.1 kernel, though the
error is also present under 2.6.18.1.  I have Debian's libaio-dev
0.3.106-3 installed.

I've written a handful of test programs that call the kernel's AIO system
calls (io_submit and io_getevents) directly.  They all exhibit the same
behavior: io_submit() calls take long enough to perform the actual I/O
operation, and io_getevents() returns instantly.  This behavior happens
whether the submitted requests are files on disk or network sockets.

I don't believe it's related to block-layer queueing, per the recent LKML
thread.  The delays happen even when I'm performing 32 parallel 512-byte
I/Os -- probably not enough to overflow any queues at the block layer.
And it happens from the very first io_submit() call, before the
block-layer queues would be full.  Changing
/sys/block/sda/queue/nr_requests has no effect.

I've attached my test program (compilation instructions included) and the
output of strace -T.  Note that nearly all io_submit calls take 10+
milliseconds, which is right where you'd expect the seek time on a laptop
hard drive to be.  Also note that the io_getevents calls return all 32
outstanding I/Os at once -- why would 32 disk seeks all finish at the same
time?

Any ideas?

--Patrick
View attachment "aiotest.c" of type "TEXT/PLAIN" (2570 bytes)

View attachment "aio.trace" of type "TEXT/PLAIN" (56629 bytes)