From: Bart Van Assche <bvanassche@acm.org>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v2 0/6] Restore data lifetime support
Date: Tue, 6 Feb 2024 10:25:32 -0800 [thread overview]
Message-ID: <abced0b9-5a0c-4627-b53b-10b0a461c564@acm.org> (raw)
In-Reply-To: <20240206-kunden-postfach-7fb32cb79486@brauner>
On 2/6/24 05:35, Christian Brauner wrote:
> On Thu, 11 Jan 2024 17:22:40 +1100, David Disseldorp wrote:
>> If initrd_start cpio extraction fails, CONFIG_BLK_DEV_RAM triggers
>> fallback to initrd.image handling via populate_initrd_image().
>> The populate_initrd_image() call follows successful extraction of any
>> built-in cpio archive at __initramfs_start, but currently performs
>> built-in archive extraction a second time.
>>
>> Prior to commit b2a74d5f9d446 ("initramfs: remove clean_rootfs"),
>> the second built-in initramfs unpack call was used to repopulate entries
>> removed by clean_rootfs(), but it's no longer necessary now the contents
>> of the previous extraction are retained.
>>
>> [...]
>
> I've pulled this in. There was a minor merge-conflict with
> fs/iomap/buffer_write.c that I've resolved. Please double-check that
> it's sane. I'll treat this branch as stable by Friday since I know you
> want to rely on it.
Thanks! The patches on the vfs.rw branch look good to me and pass my regression
tests.
> We can do it right now but I reckon that there might still be an ack or
> two incoming that you wanted.
I'm not sure acks will be incoming despite earlier promises. The following
was promised almost two years ago: "If at some point there's a desire to
actually try and upstream this support, then we'll be happy to review that
patchset." [ ... ] "As I've said multiple times, whenever code is available,
it'll be reviewed and discussed."
Sources:
* https://lore.kernel.org/linux-block/ef77ef36-df95-8658-ff54-7d8046f5d0e7@kernel.dk/,
March 2022.
* https://lore.kernel.org/linux-block/95588225-b2af-72b6-2feb-811a3b346f9f@kernel.dk/,
March 2022.
Bart.
prev parent reply other threads:[~2024-02-06 18:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 20:39 [PATCH v2 0/6] Restore data lifetime support Bart Van Assche
2024-02-02 20:39 ` [PATCH v2 1/6] fs: Fix rw_hint validation Bart Van Assche
2024-02-02 20:39 ` [PATCH v2 2/6] fs: Verify write lifetime constants at compile time Bart Van Assche
2024-02-02 20:39 ` [PATCH v2 3/6] fs: Split fcntl_rw_hint() Bart Van Assche
2024-02-02 20:39 ` [PATCH v2 4/6] fs: Move enum rw_hint into a new header file Bart Van Assche
2024-02-02 20:39 ` [PATCH v2 5/6] fs: Propagate write hints to the struct block_device inode Bart Van Assche
2024-02-02 20:39 ` [PATCH v2 6/6] block, fs: Restore the per-bio/request data lifetime fields Bart Van Assche
2024-02-05 20:46 ` Bart Van Assche
2024-02-06 13:35 ` [PATCH v2 0/6] Restore data lifetime support Christian Brauner
2024-02-06 18:25 ` Bart Van Assche [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=abced0b9-5a0c-4627-b53b-10b0a461c564@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.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;
as well as URLs for NNTP newsgroup(s).