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.