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 8134937C107 for ; Thu, 2 Apr 2026 10:59:09 +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=1775127549; cv=none; b=Oiog5sxYW8CQWGo5qG0p5i7jpK6m/EeF1Mnx21Cge5Ny9xhQ5lKvgTfAxo7KafYEJDR1b6C2gPAtxDiB3Bt1gD580TTn0+zmfg2aymY5ZU5muMs97UgfjxVCPJeIXpcDDKoWfZCSJ+e0hf1Pxfm98Cr7J92RsiB5Z8R3B4MbGgw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775127549; c=relaxed/simple; bh=KwSgJpPBsestOjU+g41fj9B15cLIwWQH15S6UdWBuGw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hvPEryWr4iQ8Ll3m+cQW1vgswYH1lwn/xS/anLk7tLm73Nu1/TLZiIafg9nL6QqWdd0X4BzQ94WMUMxJDZ/LT4IAIXzhxWNoebYKXO/XLs0eANQ/Am7JN+SAu6hG8BJrKJOBQtRiOGknXsK1T8i2lJp0sUmqbcgbylNTAPkagc8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=odDnSH9b; 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="odDnSH9b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D9EFC116C6; Thu, 2 Apr 2026 10:59:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775127549; bh=KwSgJpPBsestOjU+g41fj9B15cLIwWQH15S6UdWBuGw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=odDnSH9b7E6ukMG3v3ovytaJT0biDy3SGd5RZ0FMPfpgmV51iyNwWUGwYGPeMOpwr 3eAfeaa4C8cd7j3kekfN1JeJqsbsp9Vz0mrKJs4Pk95SiQ4k343dfLNxW+djSfM0Zf 5znUcWVFYuuRpDi1r3SiRV52wCeG/8dCSgs+UVbr5HTGACzyXD0FHrlTmJlzb2lEwF D1XCB+/yqPr9wqtWPLjUNTUTJfwvrZjZ1JWVHAom2y/uDzHi2Cq6bFVZfErC1AUrvD zDYpGOHy/TKWDO5YJzWRgnF0WPVp0z6ghvBfpqkQlCHeCgkyF0uIsq3QS/atSt16W9 +ryAG4mjn1nJA== From: Pratyush Yadav To: Chenghao Duan Cc: pasha.tatashin@soleen.com, rppt@kernel.org, pratyush@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jianghaoran@kylinos.cn Subject: Re: [PATCH v3 1/7] mm/memfd: use folio_nr_pages() for shmem inode accounting In-Reply-To: <20260326084727.118437-2-duanchenghao@kylinos.cn> (Chenghao Duan's message of "Thu, 26 Mar 2026 16:47:21 +0800") References: <20260326084727.118437-1-duanchenghao@kylinos.cn> <20260326084727.118437-2-duanchenghao@kylinos.cn> Date: Thu, 02 Apr 2026 10:59:05 +0000 Message-ID: <2vxzcy0hhbly.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 On Thu, Mar 26 2026, Chenghao Duan wrote: > memfd_luo_retrieve_folios() called shmem_inode_acct_blocks() and > shmem_recalc_inode() with hardcoded 1 instead of the actual folio > page count. memfd may use large folios (THP/hugepages), causing > quota/limit under-accounting and incorrect stat output. > > Fix by using folio_nr_pages(folio) for both functions. > > Issue found by AI review and suggested by Pratyush Yadav . > https://sashiko.dev/#/patchset/20260319012845.29570-1-duanchenghao%40kylinos.cn > > Suggested-by: Pratyush Yadav > Signed-off-by: Chenghao Duan Reviewed-by: Pratyush Yadav [...] -- Regards, Pratyush Yadav