From: Al Viro <viro@ZenIV.linux.org.uk>
To: Stafford Horne <shorne@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Lokesh Vutla <lokeshvutla@ti.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] initramfs: Always do fput() and load modules after rootfs populate
Date: Thu, 4 May 2017 19:41:48 +0100 [thread overview]
Message-ID: <20170504184148.GJ29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20170504124701.727-1-shorne@gmail.com>
On Thu, May 04, 2017 at 09:47:00PM +0900, Stafford Horne wrote:
> In OpenRISC we do not have a bootloader passed initrd, but the built in
> initramfs does contain the /init and other binaries, including modules.
> The previous commit 08865514805d2 ("initramfs: finish fput() before
> accessing any binary from initramfs") made a change to only call fput()
> if the bootloader initrd was available, this caused intermittent crashes
> for OpenRISC.
>
> This patch changes the fput() to happen unconditionally if any rootfs is
> loaded. Also, I added some comments to make it a bit more clear why we
> call unpack_to_rootfs() multiple times.
Hmm... Looks like there are two bugs: the older one (from "init, block: try
to load default elevator module early during boot") that missed the case of
said module being on built-in initramfs and then flush_delayed_fput() patch
apparently using that as a marker...
Frankly, the life would be a lot more convenient if we had the whole
populate_rootfs() run in userland. It's using the normal syscalls anyway;
the only place where it needs more is the access to initramfs images and
that could be done e.g. by offering one or two file descriptors with
splice() from those picking those images. We could build a static binary,
link _that_ into the kernel and turn the entire thing into "fork a thread,
write that sucker to rootfs, synchronously close it and do kernel_execve",
letting everything else (decompression, unpacking, etc.) done in there.
That was the original plan, actually, and that was the original motivation
for klibc. Unfortunately, klibc would have to live in the kernel tree for
that to work, and that hadn't happened. Pity, that...
Anyway, feel free to slap
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
on that patch. I can take it through vfs.git, or either of you could send
it directly to Linus - up to you.
next prev parent reply other threads:[~2017-05-04 18:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-04 7:11 [BUG] OpenRISC exec init fails, bisected to 0886551 ("initramfs: finish fput() before accessing any binary from initramfs") Stafford Horne
2017-05-04 7:45 ` Lokesh Vutla
2017-05-04 8:35 ` Stafford Horne
2017-05-04 9:09 ` Lokesh Vutla
2017-05-04 9:41 ` Stafford Horne
2017-05-04 12:47 ` [PATCH] initramfs: Always do fput() and load modules after rootfs populate Stafford Horne
2017-05-04 18:41 ` Al Viro [this message]
2017-05-05 7:43 ` Stafford Horne
2017-05-06 7:02 ` Andrei Vagin
2017-05-06 8:17 ` Stafford Horne
2017-05-06 8:23 ` Stafford Horne
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=20170504184148.GJ29622@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lokeshvutla@ti.com \
--cc=shorne@gmail.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