Received-SPF: pass (google.com: domain of linux-kernel+bounces-55454-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <abced0b9-5a0c-4627-b53b-10b0a461c564@acm.org>
Date: Tue, 6 Feb 2024 10:25:32 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/6] Restore data lifetime support
Content-Language: en-US
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>
References: <20240202203926.2478590-1-bvanassche@acm.org>
 <20240206-kunden-postfach-7fb32cb79486@brauner>
From: Bart Van Assche <bvanassche@acm.org>
In-Reply-To: <20240206-kunden-postfach-7fb32cb79486@brauner>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.