Re: Kernel Panic in skb_release_data using genet

Maxime Ripard
2022-08-15T07:07:41Z

[-- 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 --]