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 781D9289340 for ; Tue, 17 Feb 2026 12:03:43 +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=1771329823; cv=none; b=dtYSPkI7O8J7XTxVzJKNUhoZ6BeqZ6pGx/GlmnNlBjqPFp6aiDdK45T7MxV8UbJIRsmkk4sqZ9gCbcezPwr918necWzuLORruXxi5kT486SJOzPFqpXQyFAhzizqV9gxX0JXEpYNnfj0qKRxbx6Af2DGzQtXtssx3vC0UYW5e9E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771329823; c=relaxed/simple; bh=fzN3neEFA+PXd8L13+T1DVvmzIb2m3kw4M+dUTcpoLk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pREPFegQVOPr0SzPMbBFwHBLz+EL5KOmvZrCEK8vbyZviN98IaIAHum52Xp6iFLidyQbSvx07mGAe1k7CU1a5wlLRs6m9OeF97VfzWGR+Qu+Gv1YVpxGNWzFFIshza0HAKZGl6RRsHooHAMfZs72/3ZuiI9ygwRK3FrkldQ+Tts= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U5rhgHvV; 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="U5rhgHvV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FAFBC4CEF7; Tue, 17 Feb 2026 12:03:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771329823; bh=fzN3neEFA+PXd8L13+T1DVvmzIb2m3kw4M+dUTcpoLk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U5rhgHvVT3q7m+VcF1PQdOMoxiu6QUt51IUUHc/EQf/CMvvXn2K5BxSRW3hLtL5UI xl40VZE+oE9qbztcfhRcA1NckyiibWXeEuBZatDelP9fFc+b0fYfc5ax3KnHSziV3k sbcaUOW2RWGSy9Q2cSyjEY0b9pTrk0eyqNPDd+yC8ILEBArH62kBAplaUDD8lWMMsF hLVtOBhk/j6mon1grTSz79QXRtI6Z9huqhcq5dKJyBmLtv9Z1xDdqd0TofmgBHS855 hwghkvFn+dbLA70cwWVQywY0ZKLJhNDt5hjw+im2eJHry28/2kQPEwe0VEd+Mcbn6I owbeL8MLtJ/yQ== Date: Tue, 17 Feb 2026 14:03:37 +0200 From: Mike Rapoport To: Pratyush Yadav Cc: Pasha Tatashin , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] liveupdate: luo_file: remember retrieve() status Message-ID: References: <20260216132221.987987-1-pratyush@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260216132221.987987-1-pratyush@kernel.org> On Mon, Feb 16, 2026 at 02:22:19PM +0100, Pratyush Yadav wrote: > From: "Pratyush Yadav (Google)" > > LUO keeps track of successful retrieve attempts on a LUO file. It does > so to avoid multiple retrievals of the same file. Multiple retrievals > cause problems because once the file is retrieved, the serialized data > structures are likely freed and the file is likely in a very different > state from what the code expects. > > The retrieve boolean in struct luo_file keeps track of this, and is > passed to the finish callback so it knows what work was already done and > what it has left to do. > > All this works well when retrieve succeeds. When it fails, > luo_retrieve_file() returns the error immediately, without ever storing > anywhere that a retrieve was attempted or what its error code was. This > results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace, > but nothing prevents it from trying this again. > > The retry is problematic for much of the same reasons listed above. The > file is likely in a very different state than what the retrieve logic > normally expects, and it might even have freed some serialization data > structures. Attempting to access them or free them again is going to > break things. > > For example, if memfd managed to restore 8 of its 10 folios, but fails > on the 9th, a subsequent retrieve attempt will try to call > kho_restore_folio() on the first folio again, and that will fail with a > warning since it is an invalid operation. > > Apart from the retry, finish() also breaks. Since on failure the > retrieved bool in luo_file is never touched, the finish() call on > session close will tell the file handler that retrieve was never > attempted, and it will try to access or free the data structures that > might not exist, much in the same way as the retry attempt. > > There is no sane way of attempting the retrieve again. Remember the > error retrieve returned and directly return it on a retry. Also pass > this status code to finish() so it can make the right decision on the > work it needs to do. > > This is done by changing the bool to an integer. A value of 0 means > retrieve was never attempted, a positive value means it succeeded, and a > negative value means it failed and the error code is the value. > > Fixes: 7c722a7f44e0 ("liveupdate: luo_file: implement file systems callbacks") > Signed-off-by: Pratyush Yadav (Google) Reviewed-by: Mike Rapoport (Microsoft) -- Sincerely yours, Mike.