[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200420210332.7ff9652c8bdca7fb91ccfb0c@linux-foundation.org>
Date: Mon, 20 Apr 2020 21:03:32 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Nathan Chancellor <natechancellor@...il.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Arnd Bergmann <arnd@...db.de>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Jason Baron <jbaron@...mai.com>,
Catalin Marinas <catalin.marinas@....com>,
linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-arch@...r.kernel.org, linux-mm@...ck.org,
clang-built-linux@...glegroups.com
Subject: Re: [PATCH 0/6] Silence some instances of -Wtautological-compare
and enable globally
On Tue, 18 Feb 2020 21:54:17 -0700 Nathan Chancellor <natechancellor@...il.com> wrote:
> Hi everyone,
>
> This patch series aims to silence some instances of clang's
> -Wtautological-compare that are not problematic and enable it globally
> for the kernel because it has a bunch of subwarnings that can find real
> bugs in the kernel such as
> https://lore.kernel.org/lkml/20200116222658.5285-1-natechancellor@gmail.com/
> and https://bugs.llvm.org/show_bug.cgi?id=42666, which was specifically
> requested by Dmitry.
>
> The first patch adds a macro that casts the section variables to
> unsigned long (uintptr_t), which silences the warning and adds
> documentation.
>
> Patches two through four silence the warning in the places I have
> noticed it across all of my builds with -Werror, including arm, arm64,
> and x86_64 defconfig/allmodconfig/allyesconfig. There might still be
> more lurking but those will have to be teased out over time.
>
> Patch six finally enables the warning, while leaving one of the
> subwarnings disabled because it is rather noisy and somewhat pointless
> for the kernel, where core kernel code is expected to build and run with
> many different configurations where variable types can be different
> sizes.
>
For some reason none of these patches apply. Not sure why - prehaps
something in the diff headers.
Anyway, the kmemleak.c code has recently changed in ways which impact
these patches. Please take a look at that, redo, retest and resend?
Powered by blists - more mailing lists