linux-kernel - Re: [PATCH] fastboot: Introduce an asynchronous function call mechanism

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]

Date:	Wed, 15 Oct 2008 13:30:45 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	mingo@...e.hu, Evgeniy Polyakov <johnpol@....mipt.ru>
Subject: Re: [PATCH] fastboot: Introduce an asynchronous function call
 mechanism

> it's very simple. Take the case of doing each sata port probe as an
> asynchronous item. In order to keep a stable device naming/ordering,
> all the sata probes need to be done in sequence

Not really, you need the results to be ordered which simply means you
need a rendezvous and ordered dispatch from that point.

For ATA stability the only serialization points are handling out ataxx:
numbers and handing out device identifiers. You can find all the ports in
parallel and you can probe them all for disks in parallel (Power supply
permitting).

In fact in both those cases you could do it entirely in parallel as you
can order the probe sequence at start time. That in turn means that
you can defer assignation of names, but that might make the boot messages
a bit confusing.

I'd also question call_async as we don't have infinite thread resources
(or anywhere near sufficient) so in fact what you have is
queue_async(arguments)/complete_async_work(result). Also the async call
is exactly that so we need to be very careful people realise that and
don't pass pointers to local stack objects or we will have some truely
hellish debugging to do. In fact I suspect passing a single
'private_data' object as we do for irqs and other async event handlers is
far safer.

Implementing the queue_async_sequenced(arguments) /
complete_async_sequenced() / finalize_sequenced() model would make life a
lot easier for stuff like device probing with ordering as well.

	queue_async_sequenced(sequence, call, finalize, private_data)

queue asynchronous task and if resources exist start it as call(sequence,
private_data)

	complete_async_sequenced - finish this task, store result and if
possible despatch the next one

	finalize_sequenced - wait for all completions in this sequence
then run the finalize method of each strictly in the order that they were
added orginally by queue_async_sequenced.

gives us exactly what is needed for stuff like SATA probe. After the
finalize the ability to restart_async_sequenced() with a new
call/finalize function would be elegant but not essential ...

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