lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240913083426.30aff7f4@kernel.org>
Date: Fri, 13 Sep 2024 08:34:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: David Miller <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
 Mina Almasry <almasrymina@...gle.com>, Networking <netdev@...r.kernel.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux Next
 Mailing List <linux-next@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
 linuxppc-dev@...ts.ozlabs.org
Subject: Re: linux-next: build failure after merge of the net-next tree

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@...gle.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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ