linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Eli Friedman <efriedma@codeaurora.org>,
	Christopher Li <sparse@chrisli.org>,
	Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Joe Perches <joe@perches.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-sparse@vger.kernel.org
Subject: Re: [PATCH v2 2/2] Compiler Attributes: naked can be shared
Date: Thu, 20 Sep 2018 09:36:50 +0200	[thread overview]
Message-ID: <20180920073650.GA6001@nautica> (raw)
In-Reply-To: <20180920072205.GC11963@kroah.com>

Greg Kroah-Hartman wrote on Thu, Sep 20, 2018:
> "Fixes:" is not just for stable, we use it wherever we have a patch that
> we know fixes a problem introduced in another patch.
> 
> For this instance, I think we should just revert the offending patch,
> which should resolve the issue for everyone and then you can try to redo
> your series to get it right the next time.
> 
> Sound good?

Except that 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
mutually exclusive") itself fixes cafa0010cd51 ("Raise the minimum
required gcc version to 4.6"), which breaks clang altogether (as used by
example by bcc for most BPF programs, that I caught before -rc1 got
released so we got both in rc1)

I'm not aware of anything that would break if both were to be reverted,
I have no opinion on which way to go.

> Why not just route these through Andrew?  He takes lots of stuff like
> this for this very reason.

That works for me (although it might have helped if Andrew had been in
Cc at any point in this discussion...), but part of the discussion was
about seriously maintaining these files, and Miguel stepped up to help
with that so it could make sense to have his own tree.


Frankly, after this whole episode I'd find quite helpful if "compiler
stuff" (or headers maintainance in general) were to grow its own mailing
list and start being considered like a proper component of the kernel.

It does impact quite a few people, and it's neigh-impossible to review
this stuff as things are right now with a hand-picked list of CCs, no
matter how large it is -- I don't mind if it goes in -next through its
own branch or through Andrew, but a proper place where folks interested
in these could subscribe and test/review the patches would be awesome.

-- 
Dominique Martinet


  reply	other threads:[~2018-09-20  7:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-18 16:55 [PATCH v2 0/2] Compiler Attributes: (naked only, for v4.19) Miguel Ojeda
2018-09-18 16:55 ` [PATCH v2 1/2] Compiler Attributes: naked was fixed in gcc 4.6 Miguel Ojeda
2018-09-18 16:55 ` [PATCH v2 2/2] Compiler Attributes: naked can be shared Miguel Ojeda
2018-09-18 17:34   ` Greg Kroah-Hartman
2018-09-18 18:56     ` Miguel Ojeda
2018-09-19 21:14       ` Greg Kroah-Hartman
2018-09-19 23:00         ` Miguel Ojeda
2018-09-20  6:00           ` Stefan Agner
2018-09-20  7:19             ` Greg Kroah-Hartman
2018-09-20  7:20           ` Greg Kroah-Hartman
2018-09-19 23:05         ` Dominique Martinet
2018-09-19 23:56           ` Miguel Ojeda
2018-09-20  0:10             ` Dominique Martinet
2018-09-20  7:22               ` Greg Kroah-Hartman
2018-09-20  7:36                 ` Dominique Martinet [this message]
2018-09-20  7:49                   ` Geert Uytterhoeven
2018-09-20 16:11                   ` Miguel Ojeda
2018-09-20 12:18                 ` Miguel Ojeda
2018-09-20 13:57 ` [PATCH v2 0/2] Compiler Attributes: (naked only, for v4.19) Greg Kroah-Hartman
2018-09-20 13:59   ` Greg Kroah-Hartman
2018-09-20 16:13     ` Miguel Ojeda

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=20180920073650.GA6001@nautica \
    --to=asmadeus@codewreck.org \
    --cc=efriedma@codeaurora.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mingo@kernel.org \
    --cc=sparse@chrisli.org \
    --cc=torvalds@linux-foundation.org \
    --cc=yamada.masahiro@socionext.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).