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 9D4AF17A586 for ; Thu, 20 Nov 2025 20:01:58 +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=1763668918; cv=none; b=PlYSccljX+PxRXaj7hWsAaPmzEsLgSRsjyKcpIp5D2gV7aikz4g8Wgj45+RTPaoOMOvCsP5FLCS/H9X8ptpd8Sno5wYtpwyOX50Y/pawLOtZIQoefLAxP5yrPedy2HZWCPX0ddD4eN5Ha7lRA+FwbywduLeoQ09PwEBtsQaaUcg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763668918; c=relaxed/simple; bh=ZvX0wFM0qL1CtiFzpbJjufy/5/LYP6pOHRZEztLhSmA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VMny/3FfJCTA3EU0l02UmF3ygoh3gAz7Yq4afWyWtaUNrBv2TXhUVmsxcKGLjEp1i87RuWnhLPAQZBM2iAN3QPjMSaCI3s47uQOAeMLR42tC37QnstLj/s4hq+6z/LdaPxVbknM53C5Kagkq7xDX0wmtUCdf0YqsqnAtYwNPPo8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=synl6nsr; 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="synl6nsr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9507C4CEF1; Thu, 20 Nov 2025 20:01:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763668918; bh=ZvX0wFM0qL1CtiFzpbJjufy/5/LYP6pOHRZEztLhSmA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=synl6nsrM7koryVi0hr6FZQxhlPjLlbafWBhokYY8sS5/OqXPPqbsN0XP+yeyDQJB fn2p2iPvCfi1BvSCFhV5u1Q2qN6MDyaoZK0vA97C8VpPFqwUoykvzHEZlcaqFqw5mf MPCMkvHV6SZoCdV/El4CL0YSGFvRP/H7hwVsGMwuEoc/iHhmaOBS6mltuWCx29klCO MhrFWO2gJ39g5tHgax9XHO3kn8SXTxMMYOmDpIuSYLO7RKWWykQoDbrzlw+7UX0YA7 bfiqxng42Was01wyhEfy3sii1trz/aRcmolAyR8NWw6EpbW4sTdKXLFKptgow196Ds xmCfl0EPdcKvA== Message-ID: <90790838-f6aa-41e7-9f34-7d5a1e18a706@kernel.org> Date: Thu, 20 Nov 2025 21:01:52 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 2/3] mm/huge_memory: add kernel-doc for folio_split_supported() To: Zi Yan Cc: Lorenzo Stoakes , Andrew Morton , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Miaohe Lin , Naoya Horiguchi , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20251120035953.1115736-1-ziy@nvidia.com> <20251120035953.1115736-3-ziy@nvidia.com> <9D88B1A6-1D00-4770-9B66-A9A0F1B6AC15@nvidia.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <9D88B1A6-1D00-4770-9B66-A9A0F1B6AC15@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/20/25 15:48, Zi Yan wrote: > On 20 Nov 2025, at 4:27, David Hildenbrand (Red Hat) wrote: > >> On 11/20/25 04:59, Zi Yan wrote: >>> It clarifies that folio_split_supported() does not check folio->mapping and >>> can dereference it. >>> >>> Signed-off-by: Zi Yan >>> --- >>> mm/huge_memory.c | 17 +++++++++++++++++ >>> 1 file changed, 17 insertions(+) >>> >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>> index efea42d68157..15e555f1b85d 100644 >>> --- a/mm/huge_memory.c >>> +++ b/mm/huge_memory.c >>> @@ -3688,6 +3688,23 @@ static int __split_unmapped_folio(struct folio *folio, int new_order, >>> return 0; >>> } >>> +/** >>> + * folio_split_supported() - check if a folio can be split to a given order >>> + * @folio: folio to be split >>> + * @new_order: the smallest order of the after split folios (since buddy >>> + * allocator like split generates folios with orders from @folio's >>> + * order - 1 to new_order). >>> + * @split_type: uniform or non-uniform split >>> + * @warns: whether gives warnings or not for the checks in the function >>> + * >>> + * folio_split_supported() checks if @folio can be split to @new_order using >>> + * @split_type method. >>> + * >>> + * Context: Caller must make sure folio->mapping is not NULL, since the >>> + * function does not check it and can dereference folio->mapping >> >> Only for anon folios. Also, I would drop the detail about dereference. > > OK. > >> >> I guess we really need the folio lock to prevent concurrent truncation. >> >> Maybe something like: >> >> "The folio must be locked. For non-anon folios, the caller must make sure that folio->mapping is not NULL (e.g., not truncated)." > > Sure. Do you think it is worth adding VM_WARN_ONCE_ON(!folio_test_locked); > and VM_WARN_ONCE_ON(!folio->mapping); ? Makes sense. Or we allow !folio->mapping, return false and do something like the following. Still wondering how we could handle that case better. if (!folio_split_supported(folio)) { if (folio_split_temporarily_unsupported(folio)) return -EBUSY; return -EINVAL; } hmmmm -- Cheers David