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]

Date:	Tue, 12 May 2009 18:04:35 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	tom.leiming@...il.com
Cc:	arjan@...radead.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] kernel/async.c:introduce async_schedule*_atomic

On Tue, May 12, 2009 at 05:44:58PM +0200, Frederic Weisbecker wrote:
> On Tue, May 12, 2009 at 11:13:42PM +0800, tom.leiming@...il.com wrote:
> > From: Ming Lei <tom.leiming@...il.com>
> > 
> > The async_schedule* may not be called in atomic contexts if out of
> > memory or if there's too much work pending already, because the
> > async function to be called may sleep.
> > 
> > This patch fixes the comment of async_schedule*, and introduces
> > async_schedules*_atomic to allow them called from atomic contexts
> > safely.

Note that async_schedule_atomic is a confusing name.
At a first glance, it could mean that the scheduled job
will be run atomically.

I would suggest async_schedule_inatomic() so that it follows the common
naming pattern in use in the kernel, eg:

- copy_from_user_inatomic()
- futex_atomic_cmpxchg_inatomic()

and so on.

> >   * Returns an async_cookie_t that may be used for checkpointing later.
> > - * Note: This function may be called from atomic or non-atomic contexts.
> > + * Note:This function may be called from non-atomic contexts,and not
> > + * 	called from atomic contexts with safety. Please use
> > + * 	async_schedule_atomic in atomic contexts.

I suggest to add a comment which explains the reason for which it is unsafe
to call it in atomic context: because the scheduled work might be synchronously
executed.

One could believe this is because async_schedule() internally uses
a function which might sleep whereas the actual problem may come
from the scheduled function.

BTW, now that we have an atomic safe version, may be we could
also adapt the kmalloc GFP flags subsequently?

Frederic.

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