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 6F4DB3B7B6B for ; Tue, 31 Mar 2026 07:22:37 +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=1774941757; cv=none; b=eVjP36vSNVOlGeeLOwOnTWUC/SvfxDCI/gmOfCz8Av5LQ6H7qRlXWXK1VrJ+Rxwozcg8hvsyjcOaPZlnBecUNAceF5z5qSEXHZgTAmnTUyA17EOWWAFLY3wh1DOo5lPOWdx+eu27IN1sPHktsPau9qP4gVB9VUoRxD2ckRcHydQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774941757; c=relaxed/simple; bh=bqylBMF4ydyqvnzpcNQ3Ni+8LzSOq8suf1/N4xZ1WJM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oZxsY5VYH9FlPv9WiQat6lLgnBK/Z67m1Dofpl6d1g3TbIuZH995Wpbx5DCydHD9OgLiw/sTNcJj0Qhr1lFUcashrUukl76Cps4/7OPtImfsz1r+Le2orvh5YwCLqsumLZi2EIWqBSSlg0C666gcvkDDWPiaD7gXaFrFE+nr/oE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UhcsdCfz; 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="UhcsdCfz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 732C2C19423; Tue, 31 Mar 2026 07:22:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774941757; bh=bqylBMF4ydyqvnzpcNQ3Ni+8LzSOq8suf1/N4xZ1WJM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UhcsdCfzAiUk5aoX979n1D4zSHSJW0QYqSSInE0Gl6RFEhSZ6JRHX8+50No2p7/uT 25rWnD2QsUffkqSOlGyLUbY6FB+UujhzLMneR9XnNvUWKnSsNs2wEv0htN0wg/Rtjn d19faf+AAMoe6RUb2cODk6BPyqk7+czt3uFsMLdgdKGyr5V1vq4cZDZRpmbedqjPHY 8Hq7xWIAnU9QVf6Yu3wl3xS0seUnH31MkTnkEuDXDvw/dr07FA4mqeSRC0h9HH/BJj 3DgeLyKItDd+Hlm9ZLP170oI/e7PuKvzzoIUK5QFBO/7dqVVqCVvDD6LCg8OeYz7cX h65MlmRKYz1vg== Date: Tue, 31 Mar 2026 08:22:32 +0100 From: "Lorenzo Stoakes (Oracle)" To: Julian Braha Cc: akpm@linux-foundation.org, vbabka@kernel.org, hannes@cmpxchg.org, mhocko@suse.com, surenb@google.com, rppt@kernel.org, Liam.Howlett@oracle.com, david@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/thp: dead code cleanup in Kconfig Message-ID: References: <20260331070730.33915-1-julianbraha@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260331070730.33915-1-julianbraha@gmail.com> On Tue, Mar 31, 2026 at 08:07:30AM +0100, Julian Braha wrote: > There is already an 'if TRANSPARENT_HUGEPAGE' condition wrapping several > config options e.g. 'READ_ONLY_THP_FOR_FS', making > the 'depends on' statement for each of these a duplicate dependency > (dead code). > > I propose leaving the outer 'if TRANSPARENT_HUGEPAGE...endif' and removing > the individual 'depends on TRANSPARENT_HUGEPAGE' statement from each > option. > > This dead code was found by kconfirm, a static analysis tool for Kconfig. Thanks for acking tooling used :) much appreciated. > > Signed-off-by: Julian Braha Unless there's some weird semantics I'm not aware of, this LGTM, so: Reviewed-by: Lorenzo Stoakes (Oracle) > --- > mm/Kconfig | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index e8bf1e9e6ad9..29d2de0d5c06 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -810,7 +810,6 @@ if TRANSPARENT_HUGEPAGE > > choice > prompt "Transparent Hugepage Support sysfs defaults" > - depends on TRANSPARENT_HUGEPAGE > default TRANSPARENT_HUGEPAGE_ALWAYS > help > Selects the sysfs defaults for Transparent Hugepage Support. > @@ -840,7 +839,6 @@ endchoice > > choice > prompt "Shmem hugepage allocation defaults" > - depends on TRANSPARENT_HUGEPAGE > default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER > help > Selects the hugepage allocation policy defaults for > @@ -886,7 +884,6 @@ endchoice > > choice > prompt "Tmpfs hugepage allocation defaults" > - depends on TRANSPARENT_HUGEPAGE > default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER > help > Selects the hugepage allocation policy defaults for > @@ -931,7 +928,7 @@ endchoice > > config THP_SWAP > def_bool y > - depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP && 64BIT > + depends on ARCH_WANTS_THP_SWAP && SWAP && 64BIT > help > Swap transparent huge pages in one piece, without splitting. > XXX: For now, swap cluster backing transparent huge page > @@ -941,7 +938,6 @@ config THP_SWAP > > config READ_ONLY_THP_FOR_FS > bool "Read-only THP for filesystems (EXPERIMENTAL)" > - depends on TRANSPARENT_HUGEPAGE > > help > Allow khugepaged to put read-only file-backed pages in THP. > -- > 2.51.2 >