linux-kernel - Re: Approaches to making io

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: <20110901155845.GA758@samba2>
Date:	Thu, 1 Sep 2011 08:58:45 -0700
From:	Jeremy Allison <jra@...ba.org>
To:	Ulrich Drepper <drepper@...adia.org>
Cc:	Jeremy Allison <jra@...ba.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Ehrenberg <dehrenberg@...gle.com>,
	Jens Axboe <axboe@...nel.dk>, Jeff Moyer <jmoyer@...hat.com>,
	linux-kernel@...r.kernel.org, linux-aio@...ck.org
Subject: Re: Approaches to making io_submit not block

On Thu, Sep 01, 2011 at 07:14:20AM -0400, Ulrich Drepper wrote:
> On 08/31/2011 12:59 PM, Jeremy Allison wrote:
> > I get that, but isn't that what the aio_init(const struct aioinit *init) call is meant to
> > solve ?
> 
> The problem cannot be solved by something that trivial.  Any thread can
> be delayed indefinitely.  If this happens for a file descriptor chances
> are that all threads for the same file descriptor are affected while
> there is I/O for all the other file descriptors ready to run.  I don't
> say this is anywhere near optimal or even good, at least it doesn't
> amplify problems.  If you know you want more parallelism on the same
> file descriptor, dup it.

Yes I did consider that of course. Problem is that leads you to the
nightmare that is losing all fcntl locks on the file when any of the
descriptors are closed. Of course we already have internal work arounds
for that - but they're not scalable in this case.  We'd have to dup on
every read/write, and because of the fcntl lock problem we have to keep
all fd's around until the final close of the file. Don't tell us to
implement our own locking instead because (a) we already do in the case
where we don't need locking consistency with NFS and (b) most vendors insist on
locking consistency with NFS - not good if locks on one protocol aren't
seen by another.

> If you don't want anyone like me implementing
> stupid limitations finally fix the kernel aio interface so that it is
> usable.

If you know the limitation is stupid then one wonders why you added it
in the first place :-). Whatever happened to "the application writer
knows best what they are trying to do" and let us hang ourselves ?

I agree the kernel aio interface is unusable from applications, no
arguments about that.

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