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 D0B493644B7 for ; Thu, 20 Nov 2025 16:21:55 +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=1763655715; cv=none; b=jLbus+Hwkk0PsoQw3NkFfm1tl2ZcdlKIh8//3JCoKBeAFhSJUx3De/+2DtaJXoUiGtx/KqV3MestG6gALd8W8S2lniuQM3h2Xm/ZnEf8Xk0RTLAQtEld8of6sg94nXJV2ntEyQV6AUaH1firtycpmqE7sN8HhgUit7ekKjytzYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763655715; c=relaxed/simple; bh=NZKGOfpHm1+oI2EFNHX4s7/pBTvqhugD71XFSvGZD1A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OvY0pN1WvtP+Z1JVNdLtJJnYkciTUlX4EnVhaLmQuW0D0oLJ8BrNkUtPyfRYowWAsy/rQsSyHBjqx1oy0eigda6BKOdzfDHnUGC8zqG5fWDu8gDTX3vN9WD1Dbb+UgXN5GYX5587FTT0FvozxpTG+KnngUF8n1VnuTPTNcgqgFo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YiLNKzrL; 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="YiLNKzrL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97884C4CEF1; Thu, 20 Nov 2025 16:21:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763655715; bh=NZKGOfpHm1+oI2EFNHX4s7/pBTvqhugD71XFSvGZD1A=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=YiLNKzrLmFvvyKW12ItCD0e9K8K/Bt/UXrcOtHd4kC5Rn5L2X+jvujiPQWWfLuSag wYOdQxeQgrA6o3riKZyzaLVi1WGOD6j/AswJ9H0Fmr4uFm/bBij2aJ6+jF7nUXJACI Ddb5YTxdvpmmat72DvvbiUfCrmoL+cOpaLqxDCMQvkvK//QNAOymY0SJ/gWntdw2jI KJ1h0KoIBCMLX/2RXZlHyCxsrQosgqMHx9HwWnItExwZtPXlVRhzhYCsnCs0Yb/xmp FGxqBeSdI2pJf2F3OpzcMiyrUaN76KscFGrSS16j4WvLB4ZDqGV5iA1G2+zLDtN6M2 mK1Wjr6+5c5mA== Message-ID: <779100ad-a012-49ab-b2ba-b67335947481@kernel.org> Date: Thu, 20 Nov 2025 17:21:46 +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: [PATCH v2] fixup: mm/huge_memory.c: introduce folio_split_unmapped To: Balbir Singh , linux-kernel@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org Cc: Andrew Morton , Zi Yan , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Oscar Salvador , Lorenzo Stoakes , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lyude Paul , Danilo Krummrich , David Airlie , Simona Vetter , Ralph Campbell , =?UTF-8?Q?Mika_Penttil=C3=A4?= , Matthew Brost , Francois Dugast References: <20251120134232.3588203-1-balbirs@nvidia.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251120134232.3588203-1-balbirs@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/20/25 14:42, Balbir Singh wrote: > Code refactoring of __folio_split() via helper > __folio_freeze_and_split_unmapped() caused a regression with clang-20 > with CONFIG_SHMEM=n, the compiler was not able to optimize away the > call to shmem_uncharge() due to changes in nr_shmem_dropped. > Fix this by adding a stub function for shmem_uncharge when > CONFIG_SHMEM is not defined. > > smatch also complained about parameter end being used without > initialization, which is a false positive, but keep the tool happy > by sending in initialized parameters. end is initialized to 0. > smatch still complains about mapping being NULL and nr_shmem_dropped > may not be 0, but that is not true prior to or after the changes. > > Add detailed documentation comments for folio_split_unmapped() > > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Zi Yan > Cc: Joshua Hahn > Cc: Rakie Kim > Cc: Byungchul Park > Cc: Gregory Price > Cc: Ying Huang > Cc: Alistair Popple > Cc: Oscar Salvador > Cc: Lorenzo Stoakes > Cc: Baolin Wang > Cc: "Liam R. Howlett" > Cc: Nico Pache > Cc: Ryan Roberts > Cc: Dev Jain > Cc: Barry Song > Cc: Lyude Paul > Cc: Danilo Krummrich > Cc: David Airlie > Cc: Simona Vetter > Cc: Ralph Campbell > Cc: Mika Penttilä > Cc: Matthew Brost > Cc: Francois Dugast > > Suggested-by: David Hildenbrand > Signed-off-by: Balbir Singh > --- > This fixup should be squashed into the patch "mm/huge_memory.c: > introduce folio_split_unmapped" in mm/mm-unstable > > include/linux/shmem_fs.h | 6 +++++- > mm/huge_memory.c | 30 +++++++++++++++++++++--------- > 2 files changed, 26 insertions(+), 10 deletions(-) > > diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h > index 5b368f9549d6..7a412dd6eb4f 100644 > --- a/include/linux/shmem_fs.h > +++ b/include/linux/shmem_fs.h > @@ -136,11 +136,16 @@ static inline bool shmem_hpage_pmd_enabled(void) > > #ifdef CONFIG_SHMEM > extern unsigned long shmem_swap_usage(struct vm_area_struct *vma); > +extern void shmem_uncharge(struct inode *inode, long pages); I forgot to add, we drop the "extern" on functions whenever we move them. > #else > static inline unsigned long shmem_swap_usage(struct vm_area_struct *vma) > { > return 0; > } > + > +static void shmem_uncharge(struct inode *inode, long pages) "static inline void" should resolve the compilation issue. -- Cheers David