linux-kernel - Re: [PATCH 1/7] async: Asynchronous function calls to speed up kernel boot

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] [day] [month] [year] [list]

Message-ID: <20090216113126.3e54863a@gondolin>
Date:	Mon, 16 Feb 2009 11:31:26 +0100
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 1/7] async: Asynchronous function calls to speed up
 kernel boot

On Sun, 15 Feb 2009 11:16:36 -0800,
Arjan van de Ven <arjan@...radead.org> wrote:

> * The caller needs to provide the memory
>    - solves the case of the internal implementation getting a failed
>      allocation. BUT it does not solve the caller not getting memory,
>      it shifts the complexity to there.
>    - ... or needs to cope with the call potentially failing if it
>      lets the infrastructure to do the allocation

We could provide a small wrapper that allocates memory for the simple
case - but having the caller provide the memory makes it more flexible.

> * The caller needs to wait (at some point) for the operation to
>   complete, and then take care of freeing the memory.
>   (the memory obviously could be part of some natural structure that
>    already has its own lifecycle rules)

So it's not so much freeing as giving up a reference.

> * There must be enough worker threads such that deadlocks due to all
>   threads waiting on each other will not happen. Practically this
>   probably means that if there is no progress, we need to just swallow
>   the pill and make more threads. In addition we can borrow the thread
>   context of the threads that are waiting for work to complete
>   - alternative is to have 2 (or more) classes of work with a reserved
>     thread pool for each, but I'm very not fond of this idea, because
>     then all the advantages of sharing the implementation go away again,
>     and over time we'll end up with many such classes
> * The caller is not allowed to use the same memory for scheduling
>   multiple outstanding function calls (this is fundamentally different
>   from schedule_work, which does allow this).
>   - we could make a flag that marks an item as "if the function and data
>     are the same silently allow it" but I'm not too fond of that idea,
>     it'll be fragile.

Agreed, that would be fragile. The caller should be able to take care
of it best.

> Practically: the scheduled function is not allowed to make the metadata
> memory go away. At least for those cases where we later want to wait
> for the opertation; in principle we could do away with this requirement
> if we know nobody will ever wait for the operation.

But that would artificially limit the usefulness.

> Second practical issue:
> We can have a flag in the metadata that says that the infrastructure is 
> supposed to kfree() the metadata at the end.

I tried that, but didn't like the result.

> Or we can go wild and stick
> a pointer in of the function that needs to be called to free the
> metadata.

krefs start to look attractive...
--
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/