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 468A01DC9B3 for ; Sat, 25 Apr 2026 10:37:19 +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=1777113439; cv=none; b=hRwUso+D7YP7UrfSLoZm0lXGQwt05DRUkHLIpKrsOPWR0wUEQOpYJcnOg3s/HEyqzwbr8o0jPj/45bNKfGSLm1ARuupc/Xs4ItuYhvjhmU2q1YN4isMvcZ7KvyZYi2FZv9mYY0sOigHqvXd8BjRK+wSrG8FskctvS5XVqEnoxAs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777113439; c=relaxed/simple; bh=Z+2HyaTjjJqR98nfkxl6xsNcRKbg8D3ec921YsQtwL0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tTs2BHfl2cf6D7kPYpsC8SiPcyJKbCoCFr7CHdEgXnoDtw8ErI01X1uOt47wb0BoJxbvW1yqjFP4sllcqwNhqXFBvLnGGGc3sg3jlmd5Pmce2epFFrVbOMYDEaqBA9g+T0LzXTGICqQ/kYog4dhDsfgZbRUdQKuOJBSnGoOeRPk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lE3kE57K; 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="lE3kE57K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D74E4C2BCB0; Sat, 25 Apr 2026 10:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777113438; bh=Z+2HyaTjjJqR98nfkxl6xsNcRKbg8D3ec921YsQtwL0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lE3kE57KV7dqYP32LXG7tq9cEAAobUqSk/+lwLHOxjlBWu+B7cbALC5w1HduC7PsL 9B4/Nf7k1+A1GlLWBzrKfPlCXSUt9OB8aElEejJFffCKWmEXKSAhVuSuM1wT/mbnI/ 8t/oQa75mYqfFz3Zu7ZR1S05hUlybwgNe97LVgo2mdNpjwHiy2dDW5gFFHjxaiuSQ1 xRNBbmJR+3N2w9QU0h6HkaqzyHvVXMujnQj4z04fLTP/5kaeV8Chc66uzebNBv+QfI aXtei6h9sBQeK0BkHytTXSJ+ymoG8LO7x/957a3Nn8VA+ocIq8H9ILhV+fVTnA87/x ZqMQ/FXrNaNgQ== Message-ID: <111023a8-2985-4097-8b29-fe45627dc9ea@kernel.org> Date: Sat, 25 Apr 2026 12:37:12 +0200 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 2/2] uaccess: minimize INLINE_COPY_USER-related ifdefery To: Yury Norov Cc: Andrew Morton , Thomas Gleixner , "Peter Zijlstra (Intel)" , Mathieu Desnoyers , Alice Ryhl , Viktor Malik , Randy Dunlap , David Laight , linux-kernel@vger.kernel.org, Yury Norov References: <20260325163313.749336-1-ynorov@nvidia.com> <20260325163313.749336-3-ynorov@nvidia.com> <1b04dc17-baa7-47cd-b10a-01ee5a2c79b3@kernel.org> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 24/04/2026 à 21:50, Yury Norov a écrit : > On Thu, Mar 26, 2026 at 03:15:09PM +0100, Christophe Leroy (CS GROUP) wrote: >> >> >> Le 25/03/2026 à 17:33, Yury Norov a écrit : >>> Now that we've got the same knob selecting inline vs outline copy_to_user() >>> and copy_from_user(), we can simplify the corresponding logic in the >>> uaccess.h. >> >> I think we should get rid of ifdefery completly, see below. And with comment >> to previous patch, >> >> __is_defined(INLINE_COPY_TO_USER) >> >> becomes >> >> !IS_ENABLED(CONFIG_ARCH_WANT_OUTLINE_USER_COPY) > > It's out of the scope of the series. Feel free to submit a follow-up. Why ? Seting an option through a const macro in a header is historical. Nowadays this is done with Kconfig. If you are going to change INLINE_COPY_TO_USER/INLINE_COPY_FROM_USER to a new symbol, why remain with historical/deprecated practice ? > >> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h >> index 327f967a24b8..02a05dd61a77 100644 >> --- a/include/linux/uaccess.h >> +++ b/include/linux/uaccess.h >> @@ -190,10 +190,9 @@ _inline_copy_from_user(void *to, const void __user >> *from, unsigned long n) >> memset(to + (n - res), 0, res); >> return res; >> } >> -#ifndef INLINE_COPY_FROM_USER >> + >> extern __must_check unsigned long >> _copy_from_user(void *, const void __user *, unsigned long); >> -#endif >> >> static inline __must_check unsigned long >> _inline_copy_to_user(void __user *to, const void *from, unsigned long n) >> @@ -207,21 +206,19 @@ _inline_copy_to_user(void __user *to, const void >> *from, unsigned long n) >> } >> return n; >> } >> -#ifndef INLINE_COPY_TO_USER >> + >> extern __must_check unsigned long >> _copy_to_user(void __user *, const void *, unsigned long); >> -#endif > > This declares a function that may have no implementation. It's wrong. This is common practice in the kernel, what's wrong with that ? > >> static __always_inline unsigned long __must_check >> copy_from_user_common(void *to, const void __user *from, unsigned long n, >> bool partial) >> { >> if (!check_copy_size(to, n, false)) >> return n; >> -#ifdef INLINE_COPY_FROM_USER >> - return _inline_copy_from_user(to, from, n); >> -#else >> - return _copy_from_user(to, from, n); >> -#endif >> + if (__is_defined(INLINE_COPY_FROM_USER)) >> + return _inline_copy_from_user(to, from, n); >> + else >> + return _copy_from_user(to, from, n); > > To me, this is just another form of ifdefery. I prefer to minimize the > number of IS_DEFINED() blocks, just as #ifdef. But it's maybe just me. Have you read https://docs.kernel.org/process/coding-style.html#conditional-compilation ? > > Let's merge INLINE_COPY_USER series, and then see how you follow up > would look? Does this series have a real added value ? Is the churn in the arch's asm/uaccess.h worth it ? Why don't go immediatly to a Kconfig option which is the current practice nowadays ? Christophe