Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Libo Chen <libo.chen@oracle.com>
To:     gregkh@linuxfoundation.org, masahiroy@kernel.org,
        tglx@linutronix.de, peterz@infradead.org, mingo@kernel.org,
        vbabka@suse.cz, akpm@linux-foundation.org
Cc:     linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org
Subject: [PATCH RESEND 1/1] lib/Kconfig: remove DEBUG_PER_CPU_MAPS dependency for CPUMASK_OFFSTACK
Date:   Tue, 12 Apr 2022 16:15:08 -0700
Message-Id: <20220412231508.32629-2-libo.chen@oracle.com>
In-Reply-To: <20220412231508.32629-1-libo.chen@oracle.com>
References: <20220412231508.32629-1-libo.chen@oracle.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?gWTbRB+Cl6EUKpABw9DU9OxvYd9VQ18s/7jp8NfecvGPJ3DXlUsThLw1xT5q?=
 =?us-ascii?Q?JNELR/tV3KkygWJamEN/uAxMmfImCyqi+2gjS5cHkYMN1fR8fRtdHXzYRrN2?=
 =?us-ascii?Q?FTbO+IU0MorpFWfk96oP/NdSeWeREtOi49Ehpap2Vpz34SYHyjo0o2+5vIJx?=
 =?us-ascii?Q?aL4krnS1gekt0cI5drexRGzo2lzRJYF1OMQPps088oMK70uvsfIIW5ZlR+H3?=
 =?us-ascii?Q?9hjuMAPuxh7qQKr1x5wsTv5yW5X9QQQPR2M0Evcm8+0ZkCwFjszdJevXvfhg?=
 =?us-ascii?Q?ZNcfrZstDgCM1Hq9jP0H4OvTBiJ8NoFfnOBshKprRlTCBnseuF4wQEX8tEr7?=
 =?us-ascii?Q?WrUOKdXAwzBIbBaDencf9yPZ+VtlS4LHcWQM0ozCFcb0La1PbLcUoDhzTtNj?=
 =?us-ascii?Q?gjszNv2aBILaoRD6hAvuhWYnl3CIrLMQtpqLmjLID4F/hEGy1/CdqFukb3Ir?=
 =?us-ascii?Q?EvuxvuQfPH1aqpMdLLs01d/A/9k6pdqXh3+XK0NbFDTgqhkO76wJUeHJG8JU?=
 =?us-ascii?Q?ynOhMm+6Rr+KnlyGe9dqd2AlFjxrpx1oXZ4Ldr+AT3RvxWvj6GS3WDAOrpQ3?=
 =?us-ascii?Q?vt/T1aZOv3NQ7WV+89fS+3FmyLn5kZYYQ95yePKGGmjo5vPADYjcGTK25bmx?=
 =?us-ascii?Q?IZOejBFpfmYFfFN00e/F6VwfES/JeSnYc+8Oo0/5VKhQjMtl90OVWh6O4Hvs?=
 =?us-ascii?Q?KwTg5bokCTtxRNnQoAK7vzg9o9u6GgGIKzn5A4HQikE6GlJm7WNG9+ETlj8X?=
 =?us-ascii?Q?OOtggD2xq+A9Bk5dQuTq9OlHldvA0Iz6yYrtsJku7aGi3DLYtVX/N7e7tbdW?=
 =?us-ascii?Q?D7y9ioYUnjlJ2vrFbS+d6AGUlmbUYA+Xl3cv2u01ZJF9Q+VTiNVBdxvVne1z?=
 =?us-ascii?Q?t7Oi57Arm5ZMXJmowZ7EF8j1w43EvXI7Q/dUh8PpRYZPmyzWK9gkW4LvT3It?=
 =?us-ascii?Q?ar0IRqjKP9PkJFdqBt1YHSCAOqDt7nSOTS49Jtk6vis90XdSsBYGSxNOsKf6?=
 =?us-ascii?Q?BRk13EmEL5i5g0K9vyy5q4YGKRjP8fE0Co+lx0CMTE0XquxMDMGqZld2fn16?=
 =?us-ascii?Q?hIqOJ3ygDqy73Nn+TQ1EfS+xk9X/zzt1lIrrcJ7Gsar9tiUCuNA9dJVx9KDC?=
 =?us-ascii?Q?AkwEdXB40VVYcytGg+eaGJn0jygFHnBrvUulYbTePyWf9A75WCCm7MSePu9q?=
 =?us-ascii?Q?xSUvW4kGGVsfahvfRwl4t9wjR/rVi+aeBBc+n5ToQp5QmZyXgF23L9XQ152W?=
 =?us-ascii?Q?mBEVY56JeHlWWaGQRHjOQkx4G974Dug4wxfGq6AMdmCPCcAy9kF5tovoEL6Q?=
 =?us-ascii?Q?HCsFIxy6C9pR8Xo0Tr1Eod6kR5zSStGJaNYlyc4aAIEErKiVHLVXN6DJeYIL?=
 =?us-ascii?Q?8gihdQ3oHFMyTxZ1/+d4XN9HD/2WE2omH5lbCXHBD+2iks/7r11EjNNM3qtt?=
 =?us-ascii?Q?Hu2ThxenI2Z2cvvbBuciNx/FA8cF3j0D7K++V5Mnlf/N6NNDk3Kqcg56LEnO?=
 =?us-ascii?Q?vNZ4NeE1WgoRIpbg4oVPvkJeBHaGyKRDYudBTPJiDFMFd6rypBkx5HL04Xb0?=
 =?us-ascii?Q?HpdaNcnR6agmpCHZjoJ8mp6tJaN5X05woCQZanpp9wqx3EcYxbVvQz4WGSQ9?=
 =?us-ascii?Q?Cj3C2f6NQcnJRdMYAsbqUWq9YSxQZkrR2QHrz3k7K0uSP7w3PB3OTRFuCPji?=
 =?us-ascii?Q?aWmH6/UT1YUNFlIPS/pdqGqJmvoUSVNgT0WMNMl3ppGazhHHrI1Tu4mHRl8f?=
 =?us-ascii?Q?H9in6QtAGQ=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ae0bff5-03e6-41a7-630a-08da1cda4f84
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4569.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2022 23:15:19.4977
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7G+gPvtE6Z7kXWjS8P0WNYfDazs0k170XBxfU5o7MQJbM8EHSyyVu/y8z5vmTl7Hi6+58/IiXXABC+vqmKhmbA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB4030
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-04-12_06:2022-04-11,2022-04-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 adultscore=0
 phishscore=0 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2204120103
X-Proofpoint-GUID: wTA_Ikmt80bwxRZ_z14wOJ-FPdbZD7Du
X-Proofpoint-ORIG-GUID: wTA_Ikmt80bwxRZ_z14wOJ-FPdbZD7Du
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Forcing CPUMASK_OFFSTACK to be conditoned on DEBUG_PER_CPU_MAPS doesn't
make a lot of sense nowaday. Even the original patch dating back to 2008,
aab46da0520a ("cpumask: Add CONFIG_CPUMASK_OFFSTACK") didn't give any
rationale for such dependency.

Nowhere in the code supports the presumption that DEBUG_PER_CPU_MAPS is
necessary for CONFIG_CPUMASK_OFFSTACK. Make no mistake, it's good to
have DEBUG_PER_CPU_MAPS for debugging purpose or precaution, but it's
simply not a hard requirement for CPUMASK_OFFSTACK. Moreover, x86 Kconfig
already can set CPUMASK_OFFSTACK=y without DEBUG_PER_CPU_MAPS=y.
There is no reason other architectures cannot given the fact that they
have even fewer, if any, arch-specific CONFIG_DEBUG_PER_CPU_MAPS code than
x86.

Signed-off-by: Libo Chen <libo.chen@oracle.com>
---
 lib/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index 087e06b4cdfd..7209039dfb59 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -511,7 +511,7 @@ config CHECK_SIGNATURE
 	bool
 
 config CPUMASK_OFFSTACK
-	bool "Force CPU masks off stack" if DEBUG_PER_CPU_MAPS
+	bool "Force CPU masks off stack"
 	help
 	  Use dynamic allocation for cpumask_var_t, instead of putting
 	  them on the stack.  This is a bit more expensive, but avoids
-- 
2.27.0