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 07:52:46 -0400
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	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

On Wed, 15 Oct 2008 01:41:17 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:
> > +static int async_active = 0;
> 
> ?
ok will add comment

> 
> Please talk to Evgeniy about his new thread_pool stuff which I've
> suggested become a generic library.
> 
> (looks at changelog, doesn't really understand the need for the
> thread pool thing, doesn't understand the comment about device
> numbers)

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, but, say, the USB
probing can be done in parallel. This means that we need to assign the
various async tasks to specific pools (based on which device number
space they will put devices in) and can't just arbitrarily spawn them
to arbitrary threads.

> 
> > +
> > +void call_async(int pool_number, int argc, ...)
> 
> This looks like schedule_work().  Why cannot that be used (perhaps
> after suitable modification)?

as I said in the comments... the object lifetimes don't work.
We need to be able to schedule one per sata port (as per Linus'
suggest) which means we need a new work struct per function call. And
then we need something that garbage collects these, now dynamically
allocated, work structs. Which work queues just don't do. If you make
them do that... you end up with the code I wrote.

> 
> 
> 

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/