lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 09 Jan 2024 07:18:46 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Leonardo Bras" <leobras@...hat.com>,
 "Catalin Marinas" <catalin.marinas@....com>, "Will Deacon" <will@...nel.org>,
 "Eric W. Biederman" <ebiederm@...ssion.com>,
 "Kees Cook" <keescook@...omium.org>, "Oleg Nesterov" <oleg@...hat.com>,
 "Mark Brown" <broonie@...nel.org>, "Mark Rutland" <mark.rutland@....com>,
 "Steven Rostedt" <rostedt@...dmis.org>, "Guo Hui" <guohui@...ontech.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] arm64: remove unnecessary ifdefs around is_compat_task()

On Mon, Jan 8, 2024, at 18:43, Leonardo Bras wrote:
> Currently some parts of the codebase will test for CONFIG_COMPAT before
> testing is_compat_task().
>
> is_compat_task() is a inlined function only present on CONFIG_COMPAT.
> On the other hand, for !CONFIG_COMPAT, we have in linux/compat.h:
>
>  #define is_compat_task() (0)
>
> Since we have this define available in every usage of is_compat_task() for
> !CONFIG_COMPAT, it's unnecessary to keep the ifdefs, since the compiler is
> smart enough to optimize-out those snippets on CONFIG_COMPAT=n
>
> This requires some regset code as well as a few other defines to be made
> available on !CONFIG_COMPAT, so some symbols can get resolved before
> getting optimized-out.
>
> Signed-off-by: Leonardo Bras <leobras@...hat.com>
> ---
> Changes since v1:
> - Move some regset code and other defines outside of CONFIG_COMPAT
> - Closes: 
> https://lore.kernel.org/oe-kbuild-all/202401061219.Y2LD7LTx-lkp@intel.com/
> Link: 
> https://lore.kernel.org/all/20240105041458.126602-3-leobras@redhat.com/

Looks good to me, and did not cause any regressions in an overnight
randconfig build loop.

Reviewed-by: Arnd Bergmann <arnd@...db.de>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ