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

Message-ID: <20090213205949.1ebb441d@infradead.org>
Date:	Fri, 13 Feb 2009 20:59:49 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 1/7] async: Asynchronous function calls to speed up
 kernel boot

On Fri, 13 Feb 2009 16:22:00 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:

> It means that sometimes, very rarely, the callback function will be
> called within the caller's context.

for the cases that use it right now it is ok.

> 
> Hence this interface cannot be used to call might-sleep functions from
> within atomic contexts.  Which should be a major application of this
> code!

That is not what this was originally designed for. The original design
goal was to offload existing function calls out of the synchronous
execution path.

Now I understand that it would be nice to do what you propose, but it
needs a little different interface for that; specifically, the caller
will need to pass in the memory for the administration.

> 

> 
> Furthermore:
> 
> - If the callback function can sleep then the caller must be able to
>   sleep, so the GFP_ATOMIC is unneeded and undesirable, and the
> comment is wrong.

And if the callback function does not sleep it can be used in atomic
context just fine. Hence the GFP_ATOMIC.
.

> 
> I can't immediately think of a fix, apart from overhauling the
> implementation and doing it in the proper way: caller-provided storage
> rather than callee-provided (which always goes wrong).
> schedule_work() got this right.

schedule_work() got it part right. Pushing the administration to the
caller means the caller needs to allocate the memory or use static
memory and then make sure it doesn't get reused for a 2nd piece of work.
(schedule_work doesn't care, it will just execute it once in that case.
Here we do absolutely care).

The caller only rarely can deal better with the memory allocation and
lifetime rules than the implementation can. In fact, for the scenario of
"I want to take this bit of code out of the synchronous path
normally".. it is just fine and most easy this way; moving this to the
caller just makes things more fragile.

So yes based on the discussions on lkml in the last week I was going to
add an interface where you can pass in your own memory, but I want to
get the interface right such that it is low complexity for the caller,
and really hard to get wrong.. and that does involve dealing with the
"how to do static allocation while doing multiple parallel calls"
problem.

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