Re: [RFC PATCH 08/13] driver core: firmware loader: fix devicelifetime

From: Borislav Petkov
Date: Thu Jul 26 2012 - 08:20:44 EST


On Thu, Jul 26, 2012 at 10:59:08AM +0800, Ming Lei wrote:
> On Thu, Jul 26, 2012 at 12:04 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> >> Also this patch holds the reference cound of @device before
> >
> > count
>
> Good catch, will fix it in -v1.
>
>
> >> - * it is not possible to sleep for long time. It can't be called
> >> - * in atomic contexts.
> >> + * it is not possible to sleep for long time.
> >
> > Let's state it explicitly:
> >
> > "it is not allowed to sleep for it is called in atomic context."
>
> Looks you understand it incorrectly, the sentence is below
>
> * Asynchronous variant of request_firmware() for user contexts where
> * it is not possible to sleep for long time.
>
> and maybe it should be changed to below:
>
> * Asynchronous variant of request_firmware() for user contexts where
> * it is not possible to sleep for long time or can't sleep at all.

Ok, here's what I got from looking at the patch:

Your commit message says: "Also request_firmware_nowait should be called
in atomic context now, so fix the obsolete comments."

Atomic context in my book means you're not allowed to sleep at all.

But the comment says that it is possible to sleep a little. This is very
wrongly formulated AFAICT.

But, since request_firmware_nowait receives a GFP mask as one of its
arguments and some of its callers don't supply GFP_ATOMIC then this
has nothing to do with atomic contexts at all. Then, you should simply
explain in the comment why exactly callers aren't allowed to be sleeping
for a long time. And using adjectives like "long" or "short" is very
misleading in such explanations so please be more specific as to why the
callers shouldn't be sleeping for extended periods of time.

I hope I'm making sense here...

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/