Re: BUG: KASAN: stack-out-of-bounds in unwind_next_frame+0x1df5/0x2650
From: Ivan Babrou <hidden>
Date: 2021-02-04 00:54:10
Also in:
bpf, dm-devel, linux-mm, lkml
On Wed, Feb 3, 2021 at 4:17 PM Josh Poimboeuf [off-list ref] wrote:
On Wed, Feb 03, 2021 at 03:30:35PM -0800, Ivan Babrou wrote:quoted
quoted
quoted
quoted
Can you recreate with this patch, and add "unwind_debug" to the cmdline? It will spit out a bunch of stack data.Here's the three I'm building: * https://github.com/bobrik/linux/tree/ivan/static-call-5.9 It contains: * v5.9 tag as the base * static_call-2020-10-12 tag * dm-crypt patches to reproduce the issue with KASAN * x86/unwind: Add 'unwind_debug' cmdline option * tracepoint: Fix race between tracing and removing tracepoint The very same issue can be reproduced on 5.10.11 with no patches, but I'm going with 5.9, since it boils down to static call changes. Here's the decoded stack from the kernel with unwind debug enabled: * https://gist.github.com/bobrik/ed052ac0ae44c880f3170299ad4af56b See my first email for the exact commands that trigger this.Thanks. Do you happen to have the original dmesg, before running it through the post-processing script?Yes, here it is: * https://gist.github.com/bobrik/8c13e6a02555fb21cadabb74cdd6f9abIt appears the unwinder is getting lost in crypto code. No idea what this has to do with static calls though. Or maybe you're seeing multiple issues. Does this fix it?
It does for the dm-crypt case! But so does the following commit in 5.11 (and 5.10.12): * https://github.com/torvalds/linux/commit/ce8f86ee94?w=1 The reason I stuck to dm-crypt reproduction is that it reproduces reliably. We also have the following stack that doesn't touch any crypto: * https://gist.github.com/bobrik/40e2559add2f0b26ae39da30dc451f1e I cannot reproduce this one, and it took 2 days of uptime for it to happen. Is there anything I can do to help diagnose it? My goal is to enable multishot KASAN in our pre-production environment, but currently it sometimes starves TX queues on the NIC due to multiple reports in a row in an interrupt about unwind_next_frame, which disables network interface, which is not something we can tolerate.