All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Marco Elver <elver@google.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	George Popescu <georgepope@android.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	clang-built-linux@googlegroups.com, linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] ubsan: Force -Wno-maybe-uninitialized only for GCC
Date: Mon, 5 Oct 2020 23:03:46 -0700	[thread overview]
Message-ID: <202010052301.CFBC03C72E@keescook> (raw)
In-Reply-To: <20201004071614.GC1650@Ryzen-9-3900X.localdomain>

On Sun, Oct 04, 2020 at 12:16:14AM -0700, Nathan Chancellor wrote:
> On Fri, Oct 02, 2020 at 03:15:26PM -0700, Kees Cook wrote:
> > Clang handles 'maybe-uninitialized' better in the face of using UBSAN,
> > so do not make this universally disabled for UBSAN builds.
> > 
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> 
> Well this patch is not strictly necessary because Clang does not support
> -Wmaybe-uninitialized anyways :) its flags are -Wuninitialized and
> -Wsometimes-uninitialized so the warning stays enabled for UBSAN as it
> stands.

Ah, yes. Heh. Well... perhaps I can just drop this patch.

> However, something like this could still worthwhile because it would
> save us one call to cc-disable-warning (yay micro optimizations).
> 
> Maybe it just does not need to have a whole new symbol, just make it
> 
> ubsan-cflags-$(CONFIG_CC_IS_GCC)
> 
> instead of
> 
> ubsan-cflags-$(CONFIG_UBSAN)

If it gets kept, I'd still like it gated on CONFIG_UBSAN in some way
(e.g. the patch has an implicit depends due to the "if UBSAN" section).

But yes, this patch is rather a no-op.

-- 
Kees Cook

  reply	other threads:[~2020-10-06  6:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 22:15 [PATCH 0/4] Clean up UBSAN Makefile Kees Cook
2020-10-02 22:15 ` [PATCH 1/4] ubsan: Move cc-option tests into Kconfig Kees Cook
2020-10-04  7:08   ` Nathan Chancellor
2020-10-06  6:01     ` Kees Cook
2020-10-02 22:15 ` [PATCH 2/4] ubsan: Disable object-size sanitizer under GCC Kees Cook
2020-10-04  7:10   ` Nathan Chancellor
2020-10-02 22:15 ` [PATCH 3/4] ubsan: Force -Wno-maybe-uninitialized only for GCC Kees Cook
2020-10-04  7:16   ` Nathan Chancellor
2020-10-06  6:03     ` Kees Cook [this message]
2020-10-02 22:15 ` [PATCH 4/4] ubsan: Disable UBSAN_TRAP for all*config Kees Cook
2020-10-04  7:16   ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202010052301.CFBC03C72E@keescook \
    --to=keescook@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=georgepope@android.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=oberpar@linux.ibm.com \
    --cc=rdunlap@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.