From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F19B631ED8D for ; Tue, 18 Nov 2025 17:11:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763485890; cv=none; b=mflcVCGShJBcy0a9LIfO0WAVZ1Zq1rr4TzOjAAngyRX3Cc9hw8gq54xZlpVKb1+tKzEmvFxOLsh6EH8rYEejeTKohHp9W9UqZjjprN7fxHrx9Jl9waH9Zj4v3J4+9/VnmDo8j8eWoqEbp6cXEb+BIVSxz66T8n41Ywq20ZkH50A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763485890; c=relaxed/simple; bh=5JkkdNYQ6lS2Vy4m/7JD+soJwbTsSsI1qxv44jf5Qxg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=TXjAHoN+JiBvNok49bqejnPU64yQaCi3CBwqaMns7bYN+MaBblmK0F5FfxMrgnAM/IRTZdvX4bmxkkixr2zftTHjm/T86o4DkX6oacU6F5TA6JpC5k0tkR45qwg8qJEOHh4oWWDp3gzOOvN78RQixvCQTbXyP8BCVZKdALt7vjQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q45YUTFm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="q45YUTFm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C666C2BCAF; Tue, 18 Nov 2025 17:11:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763485889; bh=5JkkdNYQ6lS2Vy4m/7JD+soJwbTsSsI1qxv44jf5Qxg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=q45YUTFmc2JS/qJay40kgKnFUmQ23dQg0nbzqsc4QhJBmpbi1vTPRw6OWwKG4BUcX 5BB5rsvuq3xfamLRyekbtfqb5Qq96QILIPWV9ShluHdJqk6L9RaKTwE07NTJBVpN6l 5/6dj8Q1ySwBu0wJdfpl/NMdhwU/fXYcZS/0AhE6+5SYEDR3kPJmeH+ya98T3ciyrH asJ1TaOt7XbkJEtOe7PWaipWGFnIjO8gZEQOVRVgdx6Kkay1IA0WdBQhqgno8pkkKL T22fiGxggOUmugSmDqvIFlJx8Qn6vRwPchjhMg7GDxxLmb+KfGjx0t0aiD+8qjyhm9 7+6cJWGnwV8LA== From: Pratyush Yadav To: Pasha Tatashin Cc: Pratyush Yadav , Mike Rapoport , akpm@linux-foundation.org, bhe@redhat.com, jasonmiu@google.com, arnd@arndb.de, coxu@redhat.com, dave@vasilevsky.ca, ebiggers@google.com, graf@amazon.com, kees@kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH v1 04/13] kho: Verify deserialization status and fix FDT alignment access In-Reply-To: (Pasha Tatashin's message of "Tue, 18 Nov 2025 10:25:37 -0500") References: <20251114155358.2884014-1-pasha.tatashin@soleen.com> <20251114155358.2884014-5-pasha.tatashin@soleen.com> Date: Tue, 18 Nov 2025 18:11:24 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Nov 18 2025, Pasha Tatashin wrote: >> > This page is never freed, so adding it to zone managed pages or keeping it >> > reserved does not change anything. >> >> In practice, sure. I still don't see a good reason to _not_ initialize >> the page properly. It's not like it costs us much in terms of >> performance or code complexity. >> >> Since kho_restore_folio() makes sure the folio was _actually_ preserved >> from KHO, you have a safety check against previous kernel having a bug >> and not preserving the FDT properly. And I get that the FDT has already >> been used by this point, but at least you would have some known point to >> catch this. > > The kho_alloc_preserve() API is different from kho_preserve_folio(). > With kho_preserve_folio(), memory is allocated and some time later is > preserved, so there is a possibility for that memory to exist and be > used where it is not preserved, therefore it is a crucial step for > such memory to also do kho_restore_folio() before used. With > kho_alloc_preserve(), when the memory exists it is always preserved; > it is gurantee of this API. There is no reason to do > kho_restore_folio() on such memory at all. It can be released back to > the system via kho_free_restore()/kho_free_unpreserve(). Even for those I think there should be a kho_restore_mem() or something similar (naming things is hard :/), so they go through the restore, their struct page is properly initialized and accounted for, and make sure the pages were actually preserved. Using the memory without restoring it first should be the exception IMO. -- Regards, Pratyush Yadav