Re: [PATCH] x86/percpu: Use __force to cast from __percpu address space

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 15, 2024 at 10:03 AM Uros Bizjak <ubizjak@xxxxxxxxx> wrote:
>
> On Wed, May 15, 2024 at 9:32 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
> > > Closes: https://lore.kernel.org/lkml/CAFGhKbzev7W4aHwhFPWwMZQEHenVgZUj7=aunFieVqZg3mt14A@xxxxxxxxxxxxxx/
> > > Cc: stable@xxxxxxxxxxxxxxx # v6.8
> > > Link: https://lore.kernel.org/r/20240402175058.52649-1-ubizjak@xxxxxxxxx
> > > Signed-off-by: Uros Bizjak <ubizjak@xxxxxxxxx>
> > > ---
> > >  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@xxxxxxxxxxxxxxx # 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.





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux