From: Rob Landley <rob@landley.net>
To: Roman Pen <r.peniaev@gmail.com>
Cc: Ming Lei <ming.lei@canonical.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Randy Dunlap <rdunlap@infradead.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Michael Opdenacker <michael.opdenacker@free-electrons.com>,
Peter Zijlstra <peterz@infradead.org>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Krzysztof Mazur <krzysiek@podlesie.net>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] init: fix race between rootfs mount and firmware loading
Date: Sun, 15 Jun 2014 22:49:55 -0500 [thread overview]
Message-ID: <539E6963.6010509@landley.net> (raw)
In-Reply-To: <1402830413-4009-1-git-send-email-r.peniaev@gmail.com>
On 06/15/14 06:06, Roman Pen wrote:
> The thing is that built-in modules are being inited before
> rootfs mount. Some of the modules can request firmware loading
> using async 'request_firmware_nowait' call just while inition,
> so we can catch this kind of race: rootfs does not exist yet,
> but we are going to open and load firmware file requesting from
> the kernel.
Fixing this was on my todo list for initmpfs, along with a kernel
command line parameter to pass in size= (other than the default 50%),
and fixing the stupid "don't show initramfs in /proc/self/mountinfo
becuase rootfs is _magic_ and it's not like anything else ever gets
overmounted because nobody would _ever_ do that, no we need a magic
special case for this one thing..."
Concept seems sound, quick glance at the patch looks ok to me, my only
"can't say whether or not this is ok off the top of my head" is whether
the wakeup's being done from the right place.
Rob
prev parent reply other threads:[~2014-06-16 3:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-15 11:06 [RFC PATCH 1/1] init: fix race between rootfs mount and firmware loading Roman Pen
2014-06-16 3:49 ` Rob Landley [this message]
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=539E6963.6010509@landley.net \
--to=rob@landley.net \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@stressinduktion.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=krzysiek@podlesie.net \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.opdenacker@free-electrons.com \
--cc=ming.lei@canonical.com \
--cc=paul.gortmaker@windriver.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=r.peniaev@gmail.com \
--cc=rdunlap@infradead.org \
--cc=santosh.shilimkar@ti.com \
/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