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 67CE03CCFD4 for ; Tue, 14 Apr 2026 10:50:00 +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=1776163800; cv=none; b=s3jmrqHnsg/lQ/PiTL1dzHIozKwKaJ06/LXf+Nxn7Cjz4hLrvmaBV2dk85oU/83sIPwwDv/oEjCfeQU8NTz2mTii0uj1BDIdw2L47BpnxGaXPnt/Q5HDUx/zMuBv7zdz7LiFWKDIjgyqfrGeBNhJiSCQ13BLIkvgqlwCqawgEjg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776163800; c=relaxed/simple; bh=5dfofYZWT7uqUCmy5NQlGVWUEYkcuFDZeuPSee6W9b4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=JGgfAdKa2S/SaRI6ipoARZdBMSa23+210Tl6YTMxzH2TiukmFXwCl+U834btbziq41pBxEDm3fH85Q2NBhDlZ5fx+K5NbcHvE8OeiNyGPlpD1W4m+NycWI6lpXQN/s6Z6C3XzVWaujhpNQb0miKeLej7m9ODkx/WRulJE2oLIIM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aKhZnflz; 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="aKhZnflz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CDC1C19425; Tue, 14 Apr 2026 10:49:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776163800; bh=5dfofYZWT7uqUCmy5NQlGVWUEYkcuFDZeuPSee6W9b4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aKhZnflzHV4fEdb8h+TZmUueH8i6ZGggshJP8FJtPE0nXck0uESdDvwfAMk3wrHvx VBNV9B6giASE/DjXwbH1LrwIQWZR0lXfkDpR9LpD6oAWVb6v0srRBb2tFrRcHEiU+c sB0cSTG8kamcj89WTyJ9DguAeDw4+yt+nArjAGYqQDy1Jo0ZT8a5gNYhkuH+f+ewPc u5BOU8d4KCgmrNGf5SRqeVrX+QuFU9oMJVD2GEvyAGWeE3JBSoasGoTHAnPVO6zPyc WbmrztB25R77wVN63mApKzmVQgNk+58Omh9kdY357xoDHR0YGEoZ+QjiZTFyRANQnc ZZnQOajyqc7BA== From: Pratyush Yadav To: DaeMyung Kang Cc: pasha.tatashin@soleen.com, rppt@kernel.org, akpm@linux-foundation.org, pratyush@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: memfd_luo: fix PFN conversion in retrieve cleanup In-Reply-To: <20260413162929.156163-1-charsyam@gmail.com> (DaeMyung Kang's message of "Tue, 14 Apr 2026 01:29:29 +0900") References: <20260413162929.156163-1-charsyam@gmail.com> Date: Tue, 14 Apr 2026 10:49:56 +0000 Message-ID: <2vxzeckh95pn.fsf@kernel.org> 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 Hi DaeMyung, On Tue, Apr 14 2026, DaeMyung Kang wrote: > memfd_luo_retrieve_folios()'s error-path cleanup loop passes the raw > PFN to kho_restore_folio(), but the function expects a physical > address. The two other call sites in the same file (the discard path > and the main retrieve loop) correctly convert with PFN_PHYS() before > calling. Without the conversion the cleanup operates on the wrong > address and fails to release the folios that were preserved but not > yet inserted into the address space, leaking them across the live > update. > > Apply PFN_PHYS() to match the other call sites. > > Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd") > Signed-off-by: DaeMyung Kang Thanks, but this bug is also already fixed, by this patch [0]. [0] https://lore.kernel.org/linux-mm/20260326084727.118437-6-duanchenghao@kylinos.cn/ [...] -- Regards, Pratyush Yadav