linux-kernel - Re: [PATCH v2 0/6] Restore data lifetime support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <abced0b9-5a0c-4627-b53b-10b0a461c564@acm.org>
Date: Tue, 6 Feb 2024 10:25:32 -0800
From: Bart Van Assche <bvanassche@....org>
To: Christian Brauner <brauner@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
 "Martin K . Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCH v2 0/6] Restore data lifetime support

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.