From: Borislav Petkov <bp@amd64.org>
To: Ming Lei <ming.lei@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 08/13] driver core: firmware loader: fix device lifetime
Date: Thu, 26 Jul 2012 19:46:17 +0200 [thread overview]
Message-ID: <20120726174617.GA9161@aftab.osrc.amd.com> (raw)
In-Reply-To: <CACVXFVMxUKezcR5BBv6jM0wZr8UivF7dJGe1gLNiFx=1h4U59g@mail.gmail.com>
On Thu, Jul 26, 2012 at 11:44:48PM +0800, Ming Lei wrote:
> On Thu, Jul 26, 2012 at 8:20 PM, Borislav Petkov <bp@amd64.org> wrote:
> >
> > 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.
>
> In fact, I mean the function can be called in atomic context now, and
> I know some time ago the function will create kthread to execute
> the request_firmware, and atomic context is not allowed.
Right, but when called with GFP_KERNEL mask, it can sleep, right?
> > But the comment says that it is possible to sleep a little. This is very
> > wrongly formulated AFAICT.
>
> The function can be run in both contexts, and I don't see any words which
> says the function will sleep.
"
...
* Asynchronous variant of request_firmware() for user contexts where
* it is not possible to sleep for long time.
**/
"
Not possible to sleep for a long time means the function still *can*
sleep... even for short time. For a certain definion of "short."
> > 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
>
> It is the original one, and I don't think it is wrong. Also it
> shouldn't be covered
> by this patch.
>
> Maybe I shouldn't have fixed the comment in this patch.
Why, simply fix the comment to adhere to what the function does. And
since it can sleep, maybe the easiest fix is to say simply that:
"function can sleep", right?
--
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
next prev parent reply other threads:[~2012-07-26 17:46 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 17:00 [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware Ming Lei
2012-07-24 17:00 ` [RFC PATCH 01/13] driver core: firmware loader: simplify pages ownership transfer Ming Lei
2012-07-24 18:10 ` Borislav Petkov
2012-07-25 2:49 ` Ming Lei
2012-07-24 17:00 ` [RFC PATCH 02/13] driver core: firmware loader: fix races during loading firmware Ming Lei
2012-07-24 17:00 ` [RFC PATCH 03/13] driver core: firmware loader: remove unnecessary wmb() Ming Lei
2012-07-24 17:00 ` [RFC PATCH 04/13] driver core: firmware loader: fix creation failure of fw loader device Ming Lei
2012-07-24 17:00 ` [RFC PATCH 05/13] driver core: firmware loader: introduce firmware_buf Ming Lei
2012-07-25 13:59 ` Borislav Petkov
2012-07-26 2:51 ` Ming Lei
2012-07-26 10:08 ` Borislav Petkov
2012-07-24 17:00 ` [RFC PATCH 06/13] driver core: firmware loader: always let firmware_buf own the pages buffer Ming Lei
2012-07-25 7:55 ` Stephen Boyd
2012-07-25 14:37 ` Borislav Petkov
2012-08-03 8:34 ` Ming Lei
2012-07-25 16:02 ` Borislav Petkov
2012-07-25 16:13 ` Borislav Petkov
2012-07-24 17:00 ` [RFC PATCH 07/13] driver core: firmware loader: introduce cache_firmware and uncache_firmware Ming Lei
2012-07-25 7:54 ` Stephen Boyd
2012-07-26 2:34 ` Ming Lei
2012-07-25 15:52 ` Borislav Petkov
2012-07-26 2:40 ` Ming Lei
2012-07-24 17:00 ` [RFC PATCH 08/13] driver core: firmware loader: fix device lifetime Ming Lei
2012-07-25 16:04 ` Borislav Petkov
2012-07-26 2:59 ` Ming Lei
2012-07-26 12:20 ` Borislav Petkov
2012-07-26 15:44 ` Ming Lei
2012-07-26 17:46 ` Borislav Petkov [this message]
2012-07-27 1:30 ` Ming Lei
2012-07-27 10:32 ` Borislav Petkov
2012-07-28 14:04 ` Ming Lei
2012-07-24 17:00 ` [RFC PATCH 09/13] driver core: firmware loader: store firmware name into devres list Ming Lei
2012-07-25 16:15 ` Borislav Petkov
2012-07-26 15:15 ` Ming Lei
2012-07-24 17:00 ` [RFC PATCH 10/13] driver core: devres: introduce devres_for_each_res Ming Lei
2012-07-25 16:25 ` Borislav Petkov
2012-07-26 16:51 ` Ming Lei
2012-07-24 17:00 ` [RFC PATCH 11/13] driver core: firmware: introduce devices_cache/uncache_firmwares Ming Lei
2012-07-25 16:52 ` Borislav Petkov
2012-07-26 15:36 ` Ming Lei
2012-07-24 17:00 ` [RFC PATCH 12/13] driver core: firmware loader: use small timeout for cache device firmware Ming Lei
2012-07-26 12:36 ` Borislav Petkov
2012-07-26 15:48 ` Ming Lei
2012-07-26 17:54 ` Borislav Petkov
2012-07-27 1:54 ` Ming Lei
2012-07-27 10:35 ` Borislav Petkov
2012-07-28 13:58 ` Ming Lei
2012-07-24 17:00 ` [RFC PATCH 13/13] driver core: firmware loader: cache devices firmware during suspend/resume cycle Ming Lei
2012-07-26 12:43 ` Borislav Petkov
2012-07-26 15:49 ` Ming Lei
2012-07-24 17:08 ` [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware Ming Lei
2012-07-24 17:16 ` Linus Torvalds
2012-07-24 17:47 ` Ming Lei
2012-07-24 17:53 ` Linus Torvalds
2012-07-24 17:54 ` Linus Torvalds
2012-07-25 12:35 ` Ming Lei
2012-07-25 12:43 ` Oliver Neukum
2012-07-25 12:50 ` Ming Lei
2012-07-25 12:59 ` Ming Lei
2012-07-25 17:23 ` Linus Torvalds
2012-07-25 19:02 ` Rafael J. Wysocki
2012-07-26 2:29 ` Ming Lei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120726174617.GA9161@aftab.osrc.amd.com \
--to=bp@amd64.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=rjw@sisk.pl \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome