From: Uros Bizjak <ubizjak@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Charlemagne Lasse <charlemagnelasse@gmail.com>, stable@vger.kernel.org
Subject: Re: [PATCH] x86/percpu: Use __force to cast from __percpu address space
Date: Wed, 15 May 2024 12:15:51 +0200 [thread overview]
Message-ID: <CAFULd4bma_gVhzRkV=Ds1P8z9g-Xn_kw0XSYNnhTogJY98uUYQ@mail.gmail.com> (raw)
In-Reply-To: <CAFULd4an2qYe3L-yrfnmf3F1AZPciNemjdMEorO2BLHJX72uXg@mail.gmail.com>
On Wed, May 15, 2024 at 10:03 AM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> On Wed, May 15, 2024 at 9:32 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 14, 2024 at 10:39:18AM +0200, Uros Bizjak wrote:
> > > commit a55c1fdad5f61b4bfe42319694b23671a758cb28 upstream.
> > >
> > > Fix Sparse warning when casting from __percpu address space by using
> > > __force in the cast. x86 named address spaces are not considered to
> > > be subspaces of the generic (flat) address space, so explicit casts
> > > are required to convert pointers between these address spaces and the
> > > generic address space (the application should cast to uintptr_t and
> > > apply the segment base offset). The cast to uintptr_t removes
> > > __percpu address space tag and Sparse reports:
> > >
> > > warning: cast removes address space '__percpu' of expression
> > >
> > > Use __force to inform Sparse that the cast is intentional.
> >
> > Why is a fix for sparse required for stable kernels?
>
> Named address spaces is a new feature in the 6.8 kernel. When someone
> compiles this version with Sparse (and certain sparse parameters), it
> will spew many sparse warnings. We have fixed this in the tip tree
> (so, the fix will be in v6.9), but the tip tree diverted from the
> mainline in this area, so it was not possible to fix the issue in 6.8
> via "urgent" tip branches.
>
> I thought that the fix falls into "some “oh, that’s not good” issue"
> category (due to many sparse warnings). Also, the fix is
> straightforward with a low possibility of breaking something.
>
> > > The patch deviates from upstream commit due to the unification of
> > > arch_raw_cpu_ptr() defines in the commit:
> > >
> > > 4e5b0e8003df ("x86/percpu: Unify arch_raw_cpu_ptr() defines").
> > >
> > > Fixes: 9a462b9eafa6 ("x86/percpu: Use compiler segment prefix qualifier")
> > > Reported-by: Charlemagne Lasse <charlemagnelasse@gmail.com>
> > > Closes: https://lore.kernel.org/lkml/CAFGhKbzev7W4aHwhFPWwMZQEHenVgZUj7=aunFieVqZg3mt14A@mail.gmail.com/
> > > Cc: stable@vger.kernel.org # v6.8
> > > Link: https://lore.kernel.org/r/20240402175058.52649-1-ubizjak@gmail.com
> > > Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
> > > ---
> > > arch/x86/include/asm/percpu.h | 8 ++++----
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > And also, what kernel version(s) is this for?
>
> As instructed in the "Procedure for submitting patches to the -stable
> tree", it is stated at:
>
> Cc: stable@vger.kernel.org # v6.8
Oh, I mixed up kernel versions... this should apply to just released v6.9.
> >
> > I don't see this in any released kernels yet either, is that
> > intentional?
>
> The original fix was committed to the current mainline and will be in
> v6.9, but please also see the above reasoning. However, it is your
The original fix will be in v6.10, I mixed up the number ...
> call, so if you think that this issue is not problematic for a stable
> kernel, it's also OK with me.
Thanks,
Uros.
prev parent reply other threads:[~2024-05-15 10:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 8:39 [PATCH] x86/percpu: Use __force to cast from __percpu address space Uros Bizjak
2024-05-15 7:32 ` Greg KH
2024-05-15 8:03 ` Uros Bizjak
2024-05-15 10:15 ` Uros Bizjak [this message]
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='CAFULd4bma_gVhzRkV=Ds1P8z9g-Xn_kw0XSYNnhTogJY98uUYQ@mail.gmail.com' \
--to=ubizjak@gmail.com \
--cc=charlemagnelasse@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=stable@vger.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).