public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Andy Lutomirski <luto@kernel.org>, Nadav Amit <namit@vmware.com>,
	Brian Gerst <brgerst@gmail.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers
Date: Tue, 3 Oct 2023 15:38:02 +0200	[thread overview]
Message-ID: <ZRwZOtANkcwtL+5B@gmail.com> (raw)
In-Reply-To: <CAFULd4bBzAWoY7MDQN+YV5tpw7vDitFNMuSVt53KGofdZRvTpg@mail.gmail.com>


* Uros Bizjak <ubizjak@gmail.com> wrote:

> > Maybe, but Linus's reluctance and caution is justified IMHO, and at 
> > minimum this feature needs some careful evaluation of long-time 
> > suitability [*] ...
> 
> I do have a proposal on how to introduce a new feature while minimising 
> risk as much as possible. I must admit that detecting the feature for all 
> released compilers that can handle __seg_gs seems quite risky (I have to 
> curb my enthusiasm somehow ;) ), so perhaps a staged approach with a 
> currently unreleased compiler is more appropriate. Using:
> 
> +config CC_HAS_NAMED_AS
> +       def_bool CC_IS_GCC && GCC_VERSION >= 140000
> 
> would enable the new feature only for currently unreleased experimental 
> GCC. This would allow to qualify the compiler and weed out any possible 
> problems, before the compiler is released. Please note, that the patch is 
> written in such a way, that the code reverts to the existing approach for 
> undefined CC_HAS_NAMED_AS.

So I don't think it's a good idea to restrict it to the devel GCC version 
only, the cross-section of devel-GCC and devel-kernel reduces testing 
coverage to near-zero in practice ...

Instead, if Linus doesn't disagree that is, how about restricting it to the 
freshest GCC minor version? Ie. GCC 13.1 and later. We could carry it in a 
separate branch in -tip for a while and not merge it into v6.7 but v6.8 or 
so.

That would at least give us *some* amount of test coverage, without any 
real upstream risk.

Thanks,

	Ingo

  reply	other threads:[~2023-10-03 13:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-01 13:14 [RFC PATCH 0/4] x86/percpu: Use segment qualifiers Uros Bizjak
2023-10-01 13:14 ` [RFC PATCH 1/4] x86/percpu: Update arch/x86/include/asm/percpu.h to the current tip Uros Bizjak
2023-10-01 13:14 ` [RFC PATCH 2/4] x86/percpu: Detect compiler support for named address spaces Uros Bizjak
2023-10-01 13:14 ` [RFC PATCH 3/4] x86/percpu: Use compiler segment prefix qualifier Uros Bizjak
2023-10-01 13:14 ` [RFC PATCH 4/4] x86/percpu: Use C for percpu read/write accessors Uros Bizjak
2023-10-01 17:07 ` [RFC PATCH 0/4] x86/percpu: Use segment qualifiers Linus Torvalds
2023-10-01 19:53   ` Uros Bizjak
2023-10-01 20:21     ` Linus Torvalds
2023-10-01 20:30       ` Linus Torvalds
2023-10-01 21:47       ` Uros Bizjak
2023-10-02 12:13         ` Uros Bizjak
2023-10-02 13:22           ` Ingo Molnar
2023-10-03  9:49             ` Uros Bizjak
2023-10-03 13:38               ` Ingo Molnar [this message]
2023-10-03 19:31                 ` Linus Torvalds
2023-10-03 19:43                   ` Ingo Molnar
2023-10-03 21:43                     ` Linus Torvalds
2023-10-04  6:01                       ` Uros Bizjak
2025-04-29 16:31       ` Uros Bizjak
2025-04-29 16:49         ` Linus Torvalds
2025-04-29 17:05           ` Uros Bizjak
2025-04-29 17:44             ` Linus Torvalds

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=ZRwZOtANkcwtL+5B@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=namit@vmware.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=ubizjak@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox