linux-kernel - Re: [PATCH] kernel/async.c:introduce async_schedule*

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: <20090513094728.59d10898@gondolin>
Date:	Wed, 13 May 2009 09:47:28 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ming Lei <tom.leiming@...il.com>, arjan@...radead.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] kernel/async.c:introduce async_schedule*_atomic

On Wed, 13 May 2009 03:20:13 +0200,
Frederic Weisbecker <fweisbec@...il.com> wrote:

> On Wed, May 13, 2009 at 08:28:15AM +0800, Ming Lei wrote:

> > Also we still allow async_schedule*()  to run a job synchronously if
> > out of memory
> > or other failure. This can keep consistency with before.
> 
> 
> Yes, but also most of the current users of async_schedule() could call
> it with GFP_KERNEL. For now it's not an issue because it is not widely
> used, but who knows how that will evolve...

Well, if we want to change the interface, now would be a good time
since there are still few callers.

> 
> 
> > Any sugesstions or objections?
> 
> 
> I have shared feelings. I don't know if the dual sense of
> this new helper deserves enough disambiguation and granularity
> to be split up in two parts:
> 
> - adding an async_schedule_nosync() helper
> - add a new gfpflag_t parameter
> 
> 
> Or should we just do:
> 
> - adding async_schedule_inatomic() which is a merge of nosync + GFP_ATOMIC
> - use GFP_KERNEL in async_schedule()
> 
> 
> It depends on the future users. Will someone ever accept to schedule a job
> that could end up running synchronously in the worst case?

The current callers all look simple enough, it may be that all other
cases besides inatomic+nosync would be overkill (and a too complex api
may lead to confusion).

Do people have candidates for conversion to the async api in mind that
would need one of the complex atomic/sync or non-atomic/non-sync
versions? If no, maybe we should just use the second approach and make
sure that the semantics are well documented.
--
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/