All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Lendacky <Thomas.Lendacky@amd.com>,
	Mauro Rossi <issor.oruam@gmail.com>, Michael Matz <matz@suse.de>
Subject: Re: [PATCH] Documentation/changes: Raise minimum supported binutils version to 2.23
Date: Tue, 24 Mar 2020 17:42:05 -0400	[thread overview]
Message-ID: <20200324214204.GB3220053@rani.riverdale.lan> (raw)
In-Reply-To: <20200324164812.GG22931@zn.tnic>

On Tue, Mar 24, 2020 at 05:48:12PM +0100, Borislav Petkov wrote:
> On Tue, Mar 24, 2020 at 09:37:13AM -0700, Linus Torvalds wrote:
> > I think it's ok. It's not going to cause any _subtle_ failures, it's
> > going to cause very clear "oh, now it doesn't build" errors.
> > 
> > No?
> > 
> > And binutils 2.23 is what, 7+ years old by now and apparently had
> > known failure cases too.
> > 
> > But if there are silent and subtle failures, that might be a reason to
> > be careful. Are there?
> 
> Well, not that I know of and that's why I'm being overly cautious. Maybe
> too cautious but a lot of hectic testing of last minute fixes in the
> past have taught me to take my time.
> 
> And since it doesn't really matter when the patch goes in - there's
> always the next merge window - I would prefer to take our time and have
> it simmer in -next for max period.
> 
> So yeah, 2.23 has been tested for a long time now and it is very likely
> that nothing would happen and if you think it's ok, then sure. Then if
> you happen to see urgent pull requests with build or some other fixes,
> at least you'll be prepared. :-)
> 

This is just a documentation patch right? Nothing actually changes with
the build. The only possible thing that we would potentially have to
deal with is

(1) people noticing the doc change and complaining that they
still need to use binutils-2.21 for some reason -- but they can't
currently build an x86 kernel without patches anyway, so...

(2) people noticing the doc change and suggesting moving to 2.26 or some
later version instead of 2.23.

  reply	other threads:[~2020-03-24 21:42 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 20:23 [PATCH] x86/tools/relocs: Add _etext and __end_of_kernel_reserve to S_REL Arvind Sankar
2020-01-10 20:38 ` Borislav Petkov
2020-01-10 20:50   ` Arvind Sankar
2020-01-10 21:50     ` [PATCH v2] " Arvind Sankar
2020-01-10 21:52       ` Arvind Sankar
2020-01-11 13:02     ` [PATCH] " Borislav Petkov
2020-01-11 17:20       ` Arvind Sankar
2020-01-11 17:32         ` Arvind Sankar
2020-01-13 13:43         ` Borislav Petkov
2020-01-13 16:13           ` Arvind Sankar
2020-01-13 16:38             ` Borislav Petkov
2020-01-13 17:59               ` Arvind Sankar
2020-01-13 18:08                 ` Borislav Petkov
2020-01-14  4:17                   ` Arvind Sankar
2020-01-14 11:25                     ` Borislav Petkov
2020-01-14 16:32                       ` Arvind Sankar
2020-01-14  4:08               ` Arvind Sankar
2020-01-13 19:53             ` [PATCH v3] x86/vmlinux: Fix vmlinux.lds.S with pre-2.23 binutils Arvind Sankar
2020-01-13 21:46               ` Tom Lendacky
2020-01-13 23:06                 ` Arvind Sankar
2020-01-14  1:53               ` Kees Cook
2020-01-14  1:57                 ` H. Peter Anvin
2020-01-14  2:20                   ` Kees Cook
2020-01-14  3:58                   ` Arvind Sankar
2020-01-14  5:05                     ` hpa
2020-01-14 16:51                 ` Borislav Petkov
2020-01-14 21:50                   ` hpa
2020-01-15  0:21                   ` Arvind Sankar
2020-01-15 12:24                     ` Borislav Petkov
2020-03-16 16:02                       ` [PATCH] Documentation/changes: Raise minimum supported binutils version to 2.23 Borislav Petkov
2020-03-16 20:54                         ` Kees Cook
2020-03-23 20:44                         ` Jason A. Donenfeld
2020-03-23 20:51                           ` Kees Cook
2020-03-23 21:11                             ` Jason A. Donenfeld
2020-03-25 17:33                               ` David Laight
2020-03-24  9:02                             ` Masahiro Yamada
2020-03-24  9:12                               ` Masahiro Yamada
2020-03-24 15:38                                 ` Arvind Sankar
2020-03-24 17:31                                   ` Masahiro Yamada
2020-03-24 21:36                                     ` Arvind Sankar
2020-03-24  9:14                               ` Borislav Petkov
2020-03-24  9:40                                 ` Masahiro Yamada
2020-03-24 12:00                                   ` Borislav Petkov
2020-03-24 16:22                                 ` Jason A. Donenfeld
2020-03-24 16:28                                   ` Borislav Petkov
2020-03-24 16:37                                     ` Linus Torvalds
2020-03-24 16:48                                       ` Borislav Petkov
2020-03-24 21:42                                         ` Arvind Sankar [this message]
2020-03-24 22:01                                           ` Arvind Sankar
2020-03-24 22:14                                           ` Linus Torvalds
2020-03-24 23:49                                             ` Arvind Sankar
2020-03-24 17:53                                       ` Kees Cook
2020-03-23 20:50                         ` [PATCH] Documentation/changes: Raise minimum supported binutilsa " Nick Desaulniers
2020-01-13 23:38       ` [PATCH] x86/tools/relocs: Add _etext and __end_of_kernel_reserve to S_REL Arvind Sankar
2020-01-10 20:56   ` Kees Cook
     [not found]     ` <CAEQFVGa4fksPRtiLtBckSgbJY_JSHr07hoy5+5w-pAYym16YVg@mail.gmail.com>
2020-01-11 19:40       ` Fwd: " Mauro Rossi

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=20200324214204.GB3220053@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=Jason@zx2c4.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=issor.oruam@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=matz@suse.de \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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.