All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nsc@kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH] initramfs: correctly handle space in path on cpio list generation
Date: Tue, 10 Feb 2026 22:34:31 +1100	[thread overview]
Message-ID: <20260210223431.6bf63673.ddiss@suse.de> (raw)
In-Reply-To: <20260209153800.28228-1-ansuelsmth@gmail.com>

[cc'ing fsdevel]

On Mon,  9 Feb 2026 16:37:58 +0100, Christian Marangi wrote:

> The current gen_initramfs.sh and gen_init_cpio.c tools doesn't correctly
> handle path or filename with space in it. Although highly discouraged,

"highly discouraged" isn't really appropriate here; the kernel generally
doesn't care whether or not a filename carries whitespace.
The limitation here is specifically the gen_init_cpio manifest format,
which is strictly space-separated.

> Linux also supports filename or path with whiespace and currently this
> will produce error on generating and parsing the cpio_list file as the
> pattern won't match the expected variables order. (with gid or mode
> parsed as string)
> 
> This was notice when creating an initramfs with including the ALSA test
> files and configuration that have whitespace in both some .conf and even
> some symbolic links.
> 
> Example error:

The error messages don't really add any value here.
<snip>

> To correctly handle this problem, rework the gen_initramfs.sh and
> gen_init_cpio.c to guard all the path with "" to handle all kind of
> whitespace for filename/path.
> 
> The default_cpio_list is also updated to follow this new pattern.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
>  usr/default_cpio_list |  6 +++---
>  usr/gen_init_cpio.c   | 10 +++++-----
>  usr/gen_initramfs.sh  | 27 +++++++++++++++++++--------
>  3 files changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/usr/default_cpio_list b/usr/default_cpio_list
> index 37b3864066e8..d4a66b4aa7f7 100644
> --- a/usr/default_cpio_list
> +++ b/usr/default_cpio_list
> @@ -1,6 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  # This is a very simple, default initramfs
>  
> -dir /dev 0755 0 0
> -nod /dev/console 0600 0 0 c 5 1
> -dir /root 0700 0 0
> +dir "/dev" 0755 0 0
> +nod "/dev/console" 0600 0 0 c 5 1
> +dir "/root" 0700 0 0
> diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
> index b7296edc6626..ca5950998841 100644
> --- a/usr/gen_init_cpio.c
> +++ b/usr/gen_init_cpio.c
> @@ -166,7 +166,7 @@ static int cpio_mkslink_line(const char *line)
>  	int gid;
>  	int rc = -1;
>  
> -	if (5 != sscanf(line, "%" str(PATH_MAX) "s %" str(PATH_MAX) "s %o %d %d", name, target, &mode, &uid, &gid)) {
> +	if (5 != sscanf(line, "\"%" str(PATH_MAX) "[^\"]\" \"%" str(PATH_MAX) "[^\"]\" %o %d %d", name, target, &mode, &uid, &gid)) {

This breaks parsing of existing manifest files, so is unacceptable
IMO. If we really want to go down the route of having gen_init_cpio
support space-separated paths, then perhaps a new --field-separator
parameter might make sense. For your specific workload it seems that
simply using an external cpio archiver with space support (e.g. GNU
cpio --null) would make sense. Did you consider going down that
path?

Thanks, David

  reply	other threads:[~2026-02-10 11:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-09 15:37 [RFC PATCH] initramfs: correctly handle space in path on cpio list generation Christian Marangi
2026-02-10 11:34 ` David Disseldorp [this message]
2026-02-10 17:37   ` Christian Marangi
2026-02-11  0:43     ` David Disseldorp
2026-02-11  0:58       ` Christian Marangi
2026-02-11  2:40         ` David Disseldorp
2026-02-15  2:54           ` Christian Marangi

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=20260210223431.6bf63673.ddiss@suse.de \
    --to=ddiss@suse.de \
    --cc=0x7f454c46@gmail.com \
    --cc=ansuelsmth@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.