Date: Fri, 01 Apr 2022 21:15:39 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: "Peter Holm" <pho@FreeBSD.org> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: epoch callback panic Message-ID: <2E5707B9-63C6-4F8C-AAD5-692B14FF5DE1@lists.zabbadoz.net> In-Reply-To: <Ykdl2QBTxQT6HHld@Peters-MacBook-Air.local> References: <YkcxYahdgRUiAEqC@Peters-MacBook-Air.local> <23673db5-5798-5c06-c04c-7c680ebe41d4@selasky.org> <Ykdl2QBTxQT6HHld@Peters-MacBook-Air.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Apr 2022, at 20:51, Peter Holm wrote: > On Fri, Apr 01, 2022 at 10:33:15PM +0200, Hans Petter Selasky wrote: >> On 4/1/22 19:07, Peter Holm wrote: >>> markj@ asked me to post this one: >>> >>> panic: rw lock 0xfffff801bccb1410 not unlocked >>> cpuid = 4 >>> time = 1648770125 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe00e48a3d10 >>> vpanic() at vpanic+0x17f/frame 0xfffffe00e48a3d60 >>> panic() at panic+0x43/frame 0xfffffe00e48a3dc0 >>> _rw_destroy() at _rw_destroy+0x35/frame 0xfffffe00e48a3dd0 >>> in_lltable_destroy_lle_unlocked() at >>> in_lltable_destroy_lle_unlocked+0x1a/frame 0xfffffe00e48a3df0 >>> epoch_call_task() at epoch_call_task+0x13a/frame 0xfffffe00e48a3e40 >>> gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa7/frame >>> 0xfffffe00e48a3ec0 >>> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame >>> 0xfffffe00e48a3ef0 >>> fork_exit() at fork_exit+0x80/frame 0xfffffe00e48a3f30 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00e48a3f30 >>> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >>> >>> Details @ https://people.freebsd.org/~pho/stress/log/log0275.txt >>> >> >> Hi, >> >> Maybe you need to grab the lock before destroying it? >> > > This was on a pristine main-n254137-31190aa02eef0. If there was no other emory corruption and my memory serves me right, la_flags = 0x1 was LLE_DELETED which gives a good hint on the call path. If I had to bet it’s coming out of the 2nd condition in in_scrubprefixlle ... I’d check lltable_delete_addr .. and so on .. /bz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E5707B9-63C6-4F8C-AAD5-692B14FF5DE1>