Re: linux-next: build failure after merge of the net-next tree

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 13 Sep 2024 20:41:38 +1000 Stephen Rothwell wrote:
> I have bisected it (just using the net-next tree) to commit
> 
> 8ab79ed50cf10f338465c296012500de1081646f is the first bad commit
> commit 8ab79ed50cf10f338465c296012500de1081646f
> Author: Mina Almasry <almasrymina@google.com>
> Date:   Tue Sep 10 17:14:49 2024 +0000
> 
>     page_pool: devmem support
>     
> 
> And it may be pointing at arch/powerpc/include/asm/atomic.h line 200
> which is this:
> 
> static __inline__ s64 arch_atomic64_read(const atomic64_t *v)
> {
>         s64 t;
> 
>         /* -mprefixed can generate offsets beyond range, fall back hack */
>         if (IS_ENABLED(CONFIG_PPC_KERNEL_PREFIXED))
>                 __asm__ __volatile__("ld %0,0(%1)" : "=r"(t) : "b"(&v->counter))
> ;
>         else
>                 __asm__ __volatile__("ld%U1%X1 %0,%1" : "=r"(t) : "m<>"(v->counter));
> 
>         return t;
> }
> 
> The second "asm" above (CONFIG_PPC_KERNEL_PREFIXED is not set).  I am
> guessing by searching for "39" in net/core/page_pool.s
> 
> This is maybe called from page_pool_unref_netmem()

Thanks! The compiler version helped, I can repro with GCC 14.

It's something special about compound page handling on powerpc64,
AFAICT. I'm guessing that the assembler is mad that we're doing
an unaligned read:

   3300         ld 8,39(8)       # MEM[(const struct atomic64_t *)_29].counter, t

which does indeed look unaligned to a naked eye. If I replace
virt_to_head_page() with virt_to_page() on line 867 in net/core/page_pool.c
I get:

   2982         ld 8,40(10)      # MEM[(const struct atomic64_t *)_94].counter, t

and that's what we'd expect. It's reading pp_ref_count which is at
offset 40 in struct net_iov. I'll try to take a closer look at 
the compound page handling, with powerpc assembly book in hand, 
but perhaps this rings a bell for someone?