[PATCH 0/3] Remove volatile from arch_raw_cpu_ptr() and revert the hacks.

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2022-03-23 10:17:08 [-0700], Linus Torvalds wrote:
> I get the feeling that the real problem is that on x86, we have this:
> 
> #define arch_raw_cpu_ptr(ptr)                           \
> ({                                                      \
>         unsigned long tcp_ptr__;                        \
>         asm volatile("add " __percpu_arg(1) ", %0"      \
>                      : "=r" (tcp_ptr__)                 \
>                      : "m" (this_cpu_off), "0" (ptr));  \
>         (typeof(*(ptr)) __kernel __force *)tcp_ptr__;   \
> })
> 
> and that "volatile" is just *WRONG*.
> 
> That volatile is what literally tells the compiler "you can't remove
> this if it isn't used".

It is indeed just x86. After double checking arm/mips removes that code
properly.

> But there's no point to that.
> 
> So how about we
> 
>  (a) just revert commit 9983a9d577db4
> 
>  (b) remove that bogus 'volatile'
> 
> Doesn't that fix the problem?

The following series does that. The assembly code looks okay. In a few
simple test cases the this_cpu_ptr() usage is always created and is not
moved passed preempt_enable() statement.
The resulting vmlinux shrunk a bit. The test config lost ~2KiB:
     text      data       bss       dec      hex filename
 22533901  10722831  13963496  47220228  2d08604 vmlinux.volatile
 22531589  10722831  13971688  47226108  2d09cfc vmlinux.patched

after looking at it it was sometimes due avoiding this_cpu_ptr(),
sometimes it looked that the compiler made other decisions at the
earlier resulting to be more beneficial later on.

Sebastian