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: <Pine.LNX.4.64.0701301416250.3611@woody.linux-foundation.org>
Date:	Tue, 30 Jan 2007 14:23:10 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Zach Brown <zach.brown@...cle.com>
cc:	linux-kernel@...r.kernel.org, linux-aio@...ck.org,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: [PATCH 0 of 4] Generic AIO by scheduling stacks



On Tue, 30 Jan 2007, Linus Torvalds wrote:
> 
> But from a quick overview of the patches, I really don't see anything 
> fundamentally wrong. It needs some error checking and some limiting (I 
> _really_ don't think we want a regular user starting a thousand fibrils 
> concurrently), but it actually looks much less invasive than I thought it 
> would be.

Side note (and maybe this was obvious to people already): I would suggest 
that the "limiting" not be done the way fork() is limited ("return EAGAIN 
if you go over a limit") but be done as a per-task counting semaphore 
(down() on submit, up() on fibril exit).

So we should limit these to basically have some maximum concurrency 
factor, but rather than consider it an error to go over it, we'd just cap 
the concurrency by default, so that people can freely use asynchronous 
interfaces without having to always worry about what happens if their 
resources run out..

However, that also implies that we should probably add a "flags" parameter 
to "async_submit()" and have a FIBRIL_IMMEDIATE flag (or a timeout) or 
something to tell the kernel to rather return EAGAIN than wait. Sometimes 
you don't want to block just because you already have too much work.

Hmm?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ