Re: Kernel Panic in skb_release_data using genet

[Maxime Ripard <maxime@cerno.tech>]

[-- Attachment #1: Type: text/plain, Size: 3023 bytes --]

Hi Florian,

On Thu, Aug 11, 2022 at 08:33:58PM -0700, Florian Fainelli wrote:
> 
> 
> On 5/17/2022 12:52 AM, Maxime Ripard wrote:
> > It's not really 100% reliable, but happens 30%-50% of the time at boot
> > when KASAN is enabled. It seems like enabling KASAN increases that
> > likelihood though, it went unnoticed for some time before I started
> > having those issues again when I enabled it for something unrelated.
> > 
> > It looks like it happens in bursts though, so I would get 10-15 boots
> > fine, and then 4-5 boots with that crash.
> > 
> > Cold boot vs reboot doesn't seem to affect it in one way or the other.
> > 
> > > What version of GCC did you build your kernel with?
> > 
> > The arm64 cross-compiler packaged by Fedora, which is GCC 11.2
> > at the moment.
> > 
> > > How often does that happen? What config.txt file are you using
> > > for your Pi4 B?
> > 
> > You'll find my config.txt and kernel .config attached
> 
> OK, so this is what I have been able to reproduce so far but this does not
> appear to be very reliable to reproduce, I will try my best to hold on to
> that lead though, thanks for your patience.
> 
> # udhcpc -i eth0
> udhcpc: started, v1.35.0
> [   34.355086] bcmgenet fd580000.ethernet: configuring instance for external
> RGMII (RX delay)
> [   34.363758]
> ==================================================================
> [   34.371106] BUG: KASAN: user-memory-access in put_page+0x10/0x64
> [   34.377227] Read of size 4 at addr 01000085 by task ifconfig/165
> [   34.383338]
> [   34.384857] CPU: 0 PID: 165 Comm: ifconfig Tainted: G        W   5.19.0
> #43
> [   34.392560] Hardware name: BCM2711
> [   34.396020]  unwind_backtrace from show_stack+0x18/0x1c
> [   34.401354]  show_stack from dump_stack_lvl+0x40/0x4c
> [   34.406502]  dump_stack_lvl from kasan_report+0x8c/0xa4
> [   34.411825]  kasan_report from put_page+0x10/0x64
> [   34.416615]  put_page from skb_release_data+0x84/0x13c
> [   34.421847]  skb_release_data from __kfree_skb+0x14/0x20
> [   34.427256]  __kfree_skb from bcmgenet_rx_poll+0x504/0x6f8
> [   34.432846]  bcmgenet_rx_poll from __napi_poll.constprop.0+0x50/0x1c0
> [   34.439407]  __napi_poll.constprop.0 from net_rx_action+0x278/0x488
> [   34.445787]  net_rx_action from __do_softirq+0x268/0x390
> [   34.451197]  __do_softirq from __irq_exit_rcu+0x88/0xf8
> [   34.456521]  __irq_exit_rcu from irq_exit+0x10/0x18
> [   34.461492]  irq_exit from call_with_stack+0x18/0x20
> [   34.466553]  call_with_stack from __irq_svc+0x84/0x94
> [   34.471696] Exception stack(0xf0d337f8 to 0xf0d33840)

It looks fairly close indeed.

There's a bunch of notable differences though (user-memory-access vs
wild-memory-access, the read size) but the type of memory access error
can just be due to the randomness of the memory address we try to
access, and the read 4 vs 8 could be because you're running on ARM and
I'm running on arm64?

Thanks again for looking into it

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]