LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Arvind Sankar <email@example.com>
To: "H. Peter Anvin" <firstname.lastname@example.org>
Cc: Arvind Sankar <email@example.com>,
Roberto Sassu <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
Subject: Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs()
Date: Fri, 17 May 2019 18:17:32 -0400 [thread overview]
Message-ID: <20190517221731.GA11358@rani.riverdale.lan> (raw)
On Fri, May 17, 2019 at 02:47:31PM -0700, H. Peter Anvin wrote:
> On 5/17/19 2:02 PM, Arvind Sankar wrote:
> > On Fri, May 17, 2019 at 01:18:11PM -0700, firstname.lastname@example.org wrote:
> >> Ok... I just realized this does not work for a modular initramfs, composed at load time from multiple files, which is a very real problem. Should be easy enough to deal with: instead of one large file, use one companion file per source file, perhaps something like filename..xattrs (suggesting double dots to make it less likely to conflict with a "real" file.) No leading dot, as it makes it more likely that archivers will sort them before the file proper.
> > This version of the patch was changed from the previous one exactly to deal with this case --
> > it allows for the bootloader to load multiple initramfs archives, each
> > with its own .xattr-list file, and to have that work properly.
> > Could you elaborate on the issue that you see?
> Well, for one thing, how do you define "cpio archive", each with its own
> .xattr-list file? Second, that would seem to depend on the ordering, no,
> in which case you depend critically on .xattr-list file following the
> files, which most archivers won't do.
> Either way it seems cleaner to have this per file; especially if/as it
> can be done without actually mucking up the format.
> I need to run, but I'll post a more detailed explanation of what I did
> in a little bit.
Not sure what you mean by how do I define it? Each cpio archive will
contain its own .xattr-list file with signatures for the files within
it, that was the idea.
You need to review the code more closely I think -- it does not depend
on the .xattr-list file following the files to which it applies.
The code first extracts .xattr-list as though it was a regular file. If
a later dupe shows up (presumably from a second archive, although the
patch will actually allow a second one in the same archive), it will
then process the existing .xattr-list file and apply the attributes
listed within it. It then will proceed to read the second one and
overwrite the first one with it (this is the normal behaviour in the
kernel cpio parser). At the end once all the archives have been
extracted, if there is an .xattr-list file in the rootfs it will be
parsed (it would've been the last one encountered, which hasn't been
parsed yet, just extracted).
Regarding the idea to use the high 16 bits of the mode field in
the header that's another possibility. It would just require additional
support in the program that actually creates the archive though, which
the current patch doesn't.
next prev parent reply other threads:[~2019-05-17 22:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 16:55 [PATCH v3 0/2] initramfs: add support for xattrs in the initial ram disk Roberto Sassu
2019-05-17 16:55 ` [PATCH v3 1/2] initramfs: set extended attributes Roberto Sassu
2019-05-17 16:55 ` [PATCH v3 2/2] initramfs: introduce do_readxattrs() Roberto Sassu
2019-05-17 20:18 ` hpa
2019-05-17 21:02 ` Arvind Sankar
2019-05-17 21:10 ` Arvind Sankar
2019-05-20 8:16 ` Roberto Sassu
2019-05-17 21:47 ` H. Peter Anvin
2019-05-17 22:17 ` Arvind Sankar [this message]
2019-05-20 9:39 ` Roberto Sassu
2019-05-22 16:17 ` hpa
2019-05-22 17:22 ` Roberto Sassu
2019-05-22 19:26 ` Rob Landley
2019-05-22 20:21 ` Taras Kondratiuk
2019-05-17 21:17 ` Rob Landley
2019-05-17 21:41 ` H. Peter Anvin
2019-05-18 2:16 ` Rob Landley
2019-05-22 16:18 ` hpa
2019-05-20 8:47 ` Roberto Sassu
2019-05-17 23:09 ` kbuild test robot
2019-05-18 1:02 ` kbuild test robot
2019-05-18 5:49 ` kbuild test robot
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH v3 2/2] initramfs: introduce do_readxattrs()' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).