All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-arch@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
	Paul Burton <paul.burton@mips.com>,
	James Hogan <jhogan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	Christian Brauner <christian@brauner.io>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	linux-mips@vger.kernel.org
Subject: Re: [PATCH] signal: fix building with clang
Date: Thu, 7 Mar 2019 16:28:05 +0100	[thread overview]
Message-ID: <20190307152805.GA25101@redhat.com> (raw)
In-Reply-To: <20190307091218.2343836-1-arnd@arndb.de>

On 03/07, Arnd Bergmann wrote:
>
> clang warns about the sigset_t manipulating functions (sigaddset, sigdelset,
> sigisemptyset, ...) because it performs semantic analysis before discarding
> dead code, unlike gcc that does this in the reverse order.
>
> The result is a long list of warnings like:
>
> In file included from arch/arm64/include/asm/ftrace.h:21:
> include/linux/compat.h:489:10: error: array index 3 is past the end of the array (which contains 2 elements) [-Werror,-Warray-bounds]
>         case 2: v.sig[3] = (set->sig[1] >> 32); v.sig[2] = set->sig[1];

stupid question... I have no idea if this can work or not, but may be we can just do

	--- x/Makefile
	+++ x/Makefile
	@@ -701,6 +701,7 @@ KBUILD_CPPFLAGS += $(call cc-option,-Qun
	 KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
	 KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
	 KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
	+KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds)
	 # Quiet clang warning: comparison of unsigned expression < 0 is always false
	 KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
	 # CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the

?

> As a (rather ugly) workaround,

Yes :/

But I am not going to argue, just a couple of questions.

> I turn the nice switch()/case statements
> into preprocessor conditionals, and where that is not possible, use the
> '%' operator

I can't say what looks worse... to me it would be either use ifdef's or %'s
everywhere in signal.h, with this patch the code doesn't look consistent.
But I won't insist.


>  static inline int sigisemptyset(sigset_t *set)
>  {
> -	switch (_NSIG_WORDS) {
> -	case 4:
> -		return (set->sig[3] | set->sig[2] |
> -			set->sig[1] | set->sig[0]) == 0;
> -	case 2:
> -		return (set->sig[1] | set->sig[0]) == 0;
> -	case 1:
> -		return set->sig[0] == 0;
> -	default:
> -		BUILD_BUG();
> -		return 0;
> -	}
> +#if _NSIG_WORDS == 4
> +	return (set->sig[3] | set->sig[2] |
> +		set->sig[1] | set->sig[0]) == 0;
> +#elif _NSIG_WORDS == 2
> +	return (set->sig[1] | set->sig[0]) == 0;
> +#elif _NSIG_WORDS == 1
> +	return set->sig[0] == 0;
> +#else
> +	BUILD_BUG();
> +#endif
>  }

Or perhaps we can simply rewrite this and other helpers?

I don't think that, say,

	static inline int sigisemptyset(sigset_t *set)
	{
		for (i = 0; i < ARRAY_SIZE(set->sig); ++i)
			set->sig[i] = 0;
	}

will make asm worse...

Oleg.

  parent reply	other threads:[~2019-03-07 15:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-07  9:11 [PATCH] signal: fix building with clang Arnd Bergmann
2019-03-07 10:03 ` Christian Brauner
2019-03-07 15:28 ` Oleg Nesterov [this message]
2019-03-07 15:37   ` Arnd Bergmann
2019-03-07 16:46     ` Oleg Nesterov
2019-03-07 18:41       ` Nick Desaulniers
2019-03-07 21:45       ` Arnd Bergmann
2019-03-08  0:22         ` Nick Desaulniers
2019-03-08  0:27           ` Joe Perches
2019-03-08 21:09             ` Nick Desaulniers

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=20190307152805.GA25101@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=christian@brauner.io \
    --cc=deepa.kernel@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=gustavo@embeddedor.com \
    --cc=jhogan@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.