linux-kernel - Re: async I/O seems to be blocking on 2.6.15

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: <20061106160250.GY13555@kernel.dk>
Date:	Mon, 6 Nov 2006 17:02:51 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Phillip Susi <psusi@....rr.com>
Cc:	Brent Baccala <cosine@...esoft.org>, linux-kernel@...r.kernel.org
Subject: Re: async I/O seems to be blocking on 2.6.15

On Mon, Nov 06 2006, Phillip Susi wrote:
> Jens Axboe wrote:
> >Yeah, I'm afraid so. We really should be returning EAGAIN or something
> >like that for the congested condition, though.
> 
> How would user mode know when it was safe to retry the request?

You could optimistically retry when you had reaped some completed
events, or use some controlled way of blocking for free request
notification. There are many ways, most of them share the fact that the
time between notification and new io_submit() may change the picture, in
which case you'd get EAGAIN once more.

The important bit is imho to make the blocking at least deterministic.
At some point you _have_ to block for resources, but it's not very
polite to be blocking for a considerable time indeterministically.

-- 
Jens Axboe

-
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/