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 BDCB1390CAA for ; Tue, 14 Apr 2026 10:48:35 +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=1776163715; cv=none; b=oBFfLZn51rmhr4OyNn2qx8b8xnA2pcyGMIpmADab6cLautbr7XSpIsV8yhcE7EW1dk7X98Nk/cVBsPCc3IbtsTkFyBinYs3Jo+f2sHjR2tdMmZPrwPx2V5l9j2jCPiDKgWrsbBNB2OUZh+e7wieqU9caoBy0LMC7qpj63YzgxdA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776163715; c=relaxed/simple; bh=FcuOSY66nnyC/9KTZ8YOG6PDQjM+7tRpQL3hXqVwo/0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=HsIER1XFU+9nHVARJTMdKunZIiLWnvj4U3wICH0EhreT65ppoURPLiHwGRv8ZKltind+1aIS/ZrB28KGHuRs5htFSqcsE+OESb/9kBiMTMb91mjf/YB0grtz7kZgzTnNwZPM5e/wUGN8cEhr9Le0ysWyR1ajpNdh1ni3uMGXKis= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UeOFDlJj; 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="UeOFDlJj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEE4BC19425; Tue, 14 Apr 2026 10:48:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776163715; bh=FcuOSY66nnyC/9KTZ8YOG6PDQjM+7tRpQL3hXqVwo/0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UeOFDlJjm5T2Bk/qNnZm6+wzFjUl6kO74MwQ8W+rF2ClMvhXSMCLaEnG8nEcEh0e8 7t3jJbBKOcSnpnLLB8ATQ3auwto2XRu/tV3fna6WYLFjg6mnNc3OMV1+RnFEeVjF7T khyXbrBVphkeDwDcmUhxuoS61pp9yC9fnVEaMrQYRdx6T5G1qr0pWWjH8EYUlcLD4C +FPiUQXt4AsQdgRtb/ud8Lyg9T0vWtYWx6sx9nZfO9N0VQ/aTU7otBrajsOBuHnvO5 qUoKklGcDEf8L1LUt4cgp0wKt9UgJ14tLatseFzsVuwFfErTj5oNu6dLTbFhRY/L3l yCLK1/G9ifRDQ== 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: account restored large folios correctly In-Reply-To: <20260413165053.164338-1-charsyam@gmail.com> (DaeMyung Kang's message of "Tue, 14 Apr 2026 01:50:53 +0900") References: <20260413165053.164338-1-charsyam@gmail.com> Date: Tue, 14 Apr 2026 10:48:32 +0000 Message-ID: <2vxzik9t95rz.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() always passes 1 to > shmem_inode_acct_blocks() and shmem_recalc_inode(), even when the > restored folio spans multiple pages. > > That mismatches the normal shmem path: shmem_add_to_page_cache() > accounts the folio in mapping->nrpages using folio_nr_pages(folio), > and shmem_alloc_and_add_folio() passes the same page count to > shmem_inode_acct_blocks() and shmem_recalc_inode(). > > As a result, restored large folios are under-accounted in shmem inode > and block accounting. > > Use folio_nr_pages(folio) here as well. > > Fixes: b3749f174d68 ("mm: memfd_luo: allow preserving memfd") > Signed-off-by: DaeMyung Kang Thanks for the patch. This bug is already fixed by this patch [0]. [0] https://lore.kernel.org/linux-mm/20260326084727.118437-2-duanchenghao@kylinos.cn/ [...] -- Regards, Pratyush Yadav