Date: Wed, 20 Oct 2021 15:28:39 +0000 From: bugzilla-noreply@freebsd.org To: testing@FreeBSD.org Subject: [Bug 259157] Test case sys.netgraph.hub.loop panics RISC-V kernel Message-ID: <bug-259157-32464-tZr7O969yN@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-259157-32464@https.bugs.freebsd.org/bugzilla/> References: <bug-259157-32464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259157 Mitchell Horne <mhorne@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://reviews.freebsd.org | |/D32580 Status|Open |In Progress --- Comment #5 from Mitchell Horne <mhorne@freebsd.org> --- (In reply to Lutz Donnerhacke from comment #4) The expected behaviour for a page fault in the kernel is to panic, with a couple exceptions. Certainly, anything that overflows the thread's kernel s= tack in this way will cause this. I managed to identify why this panics riscv, and not amd64. Turns out, the recursion is avoided when the architecture defines GET_STACK_USAGE(), as it allows for an early return from ng_snd_item(). The test also causes panics = on 32-bit arm, but we did not notice because the armv7 CI is broken :( I created a patch which implements the missing macro for remaining archs, a= nd it 'fixes' the panics in this test. See: https://reviews.freebsd.org/D32580 Still, I wonder if the test is flawed? If it is expected that the test might overflow the kernel stack then it is not really safe for CI. Maybe the test needs rethinking, or additional safeguards. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-259157-32464-tZr7O969yN>