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@xxxxxxxxxx>
> 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?
