Date: Fri, 12 Jun 2026 03:15:03 +0300 From: Aleksandr Rybalko <ray@freebsd.org> To: Ryan Libby <rlibby@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, current@freebsd.org, imp@freebsd.org Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex vtbuf @ .. Message-ID: <CAJ1Oi8H9Z5U-tvGUA6q-cO-xga%2Bxfa-9C5m%2BK1yXdEJSGiJmKw@mail.gmail.com> In-Reply-To: <CAHgpiFxY5%2BG0NPL_fykvkoFOaLvO13_vL2PuwuA5xRdrURWAUA@mail.gmail.com> References: <n75ors8s-1762-996-oqn1-pqs4os5sos0@mnoonqbm.arg> <CAHgpiFzcU12khmHFJTfLG4BVk%2BDCXvXpOJWZBZ_PfQAp_V_OfA@mail.gmail.com> <CAJ1Oi8HkSMKZ1vRXgm27kgiV0RkLac%2BbB2abZVURBLwy_7kHQQ@mail.gmail.com> <CAJ-VmongFcz4JShZtnddAdytCiMQne3br7vXjuAS90PbGA2roQ@mail.gmail.com> <CAJ1Oi8FNAsDJY4H3J_AeXhoCwwRQHdwjJSryLNptWVyUCv1ejw@mail.gmail.com> <CAHgpiFxY5%2BG0NPL_fykvkoFOaLvO13_vL2PuwuA5xRdrURWAUA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Fixed with mtx_owned(9) test yet. See https://github.com/freebsd/freebsd-src/commit/1f68ca5802db91bd9725bcdbf55932e104dbe95d Thanks! сб, 6 черв. 2026 р. о 03:17 Ryan Libby <rlibby@freebsd.org> пише: > On Tue, Jun 2, 2026 at 3:01 PM Aleksandr Rybalko <ray@freebsd.org> wrote: > > > > Hey, Adrian! > > > > Know why, but working on a fix yet. > > > > Thanks! > > > > вт, 2 черв. 2026 р. о 20:01 Adrian Chadd <adrian@freebsd.org> пише: > >> > >> hey! was this eventually fixed? I just hit it, notably a few days old > >> -head (i think), but I still hit it. > >> > >> THanks! > >> > >> > >> -a > >> > >> On Fri, 22 May 2026 at 08:51, Aleksandr Rybalko <ray@freebsd.org> > wrote: > >> > > >> > Hey guys! > >> > > >> > Yeah, it seems my. > >> > I will look into it today. > >> > > >> > Thanks! > >> > > >> > пт, 22 трав. 2026 р. о 18:35 Ryan Libby <rlibby@freebsd.org> пише: > >> >> > >> >> On Fri, May 22, 2026 at 1:46 AM Bjoern A. Zeeb > >> >> <bzeeb-lists@lists.zabbadoz.net> wrote: > >> >> > > >> >> > Hi, > >> >> > > >> >> > I was using the mouse in tmux on v1 when everying stopped. > >> >> > Sadly we didn't switch to v0 for console but it seems I managed to > get a dump only checking now; the kernel from then is already gone. > >> >> > > >> >> > core.txt said. > >> >> > > >> >> > panic: mtx_lock_spin: recursed on non-recursive mutex vtbuf @ > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:744 > >> >> > > >> >> > cpuid = 1 > >> >> > time = 1779437567 > >> >> > KDB: stack backtrace: > >> >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00d773e7a0 > >> >> > vpanic() at vpanic+0x149/frame 0xfffffe00d773e8d0 > >> >> > panic() at panic+0x43/frame 0xfffffe00d773e930 > >> >> > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x11b/frame > 0xfffffe00d773e970 > >> >> > vtbuf_flush_mark() at vtbuf_flush_mark+0x82/frame > 0xfffffe00d773e9b0 > >> >> > vtbuf_unmark_on_cross() at vtbuf_unmark_on_cross+0xcc/frame > 0xfffffe00d773e9d0 > >> >> > vtterm_fill() at vtterm_fill+0x27/frame 0xfffffe00d773ea00 > >> >> > teken_subr_erase_line() at teken_subr_erase_line+0x90/frame > 0xfffffe00d773ea20 > >> >> > teken_state_2() at teken_state_2+0x497/frame 0xfffffe00d773ea40 > >> >> > teken_input_char() at teken_input_char+0x47/frame > 0xfffffe00d773ea60 > >> >> > teken_input() at teken_input+0x9f/frame 0xfffffe00d773ea90 > >> >> > termtty_outwakeup() at termtty_outwakeup+0xcf/frame > 0xfffffe00d773eb60 > >> >> > ttydisc_write() at ttydisc_write+0x337/frame 0xfffffe00d773ecd0 > >> >> > ttydev_write() at ttydev_write+0x13f/frame 0xfffffe00d773ed10 > >> >> > devfs_write_f() at devfs_write_f+0xf3/frame 0xfffffe00d773ed70 > >> >> > dofilewrite() at dofilewrite+0x81/frame 0xfffffe00d773edc0 > >> >> > sys_writev() at sys_writev+0x69/frame 0xfffffe00d773ee00 > >> >> > amd64_syscall() at amd64_syscall+0x168/frame 0xfffffe00d773ef30 > >> >> > fast_syscall_common() at fast_syscall_common+0xf8/frame > 0xfffffe00d773ef30 > >> >> > --- syscall (121, FreeBSD ELF64, writev), rip = 0x82601d5aa, rsp = > 0x8207a3408, rbp = 0x8207a3430 --- > >> >> > KDB: enter: panic > >> >> > > >> >> > > >> >> > In case it helps, I believe this is file:line as reported by gdb > in core.txt: > >> >> > > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/kern_mutex.c:353 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:744 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:864 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:210 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:232 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_core.c:1201 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:121 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken_subr.h:558 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:255 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:284 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:317 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/subr_terminal.c:422 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/sys/ttydevsw.h:114 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/tty_ttydisc.c:658 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/tty.c:550 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/fs/devfs/devfs_vnops.c:1980 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/sys/file.h:372 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:565 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:492 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:478 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/amd64/amd64/../../kern/subr_syscall.c:193 > >> >> > > >> >> > > >> >> > -- > >> >> > Bjoern A. Zeeb > r15:7 > >> >> > > >> >> > >> >> I think it's probably related to or a regression from > >> >> 8db0553ed6d8 ("vt: Clear cut-paste selection if the area intersects > >> >> with the filled region") > >> >> > https://cgit.freebsd.org/src/commit/?id=8db0553ed6d8636d82a26896237099526b93be19 > >> >> > >> >> which added vtbuf_unmark_on_cross() which is in your panic stack. > >> >> > >> >> I don't know this code but it looks like the mutex is first taken by > >> >> teken_input / teken_funcs_pre_input / vtterm_pre_input and then again > >> >> by teken_input with your panic stack. > >> >> > >> >> Ryan > > How is the locking supposed to work in vt_mouse_event anyway? > > Unsolicited suggestion: require that the vb_lock be held on entry to > vtbuf_set_mark, remove the lock acquisition from vtbuf_flush_mark, and > make the call path through vt_mouse_event to vtbuf_set_mark and > vtbuf_unmark acquire the lock. > > Ryan > [-- Attachment #2 --] <div dir="ltr"><div>Fixed with mtx_owned(9) test yet.<br></div><div>See <a href="https://github.com/freebsd/freebsd-src/commit/1f68ca5802db91bd9725bcdbf55932e104dbe95d">https://github.com/freebsd/freebsd-src/commit/1f68ca5802db91bd9725bcdbf55932e104dbe95d</a></div><div><br></div><div>Thanks!</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">сб, 6 черв. 2026 р. о 03:17 Ryan Libby <<a href="mailto:rlibby@freebsd.org">rlibby@freebsd.org</a>> пише:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 2, 2026 at 3:01 PM Aleksandr Rybalko <<a href="mailto:ray@freebsd.org" target="_blank">ray@freebsd.org</a>> wrote:<br> ><br> > Hey, Adrian!<br> ><br> > Know why, but working on a fix yet.<br> ><br> > Thanks!<br> ><br> > вт, 2 черв. 2026 р. о 20:01 Adrian Chadd <<a href="mailto:adrian@freebsd.org" target="_blank">adrian@freebsd.org</a>> пише:<br> >><br> >> hey! was this eventually fixed? I just hit it, notably a few days old<br> >> -head (i think), but I still hit it.<br> >><br> >> THanks!<br> >><br> >><br> >> -a<br> >><br> >> On Fri, 22 May 2026 at 08:51, Aleksandr Rybalko <<a href="mailto:ray@freebsd.org" target="_blank">ray@freebsd.org</a>> wrote:<br> >> ><br> >> > Hey guys!<br> >> ><br> >> > Yeah, it seems my.<br> >> > I will look into it today.<br> >> ><br> >> > Thanks!<br> >> ><br> >> > пт, 22 трав. 2026 р. о 18:35 Ryan Libby <<a href="mailto:rlibby@freebsd.org" target="_blank">rlibby@freebsd.org</a>> пише:<br> >> >><br> >> >> On Fri, May 22, 2026 at 1:46 AM Bjoern A. Zeeb<br> >> >> <<a href="mailto:bzeeb-lists@lists.zabbadoz.net" target="_blank">bzeeb-lists@lists.zabbadoz.net</a>> wrote:<br> >> >> ><br> >> >> > Hi,<br> >> >> ><br> >> >> > I was using the mouse in tmux on v1 when everying stopped.<br> >> >> > Sadly we didn't switch to v0 for console but it seems I managed to get a dump only checking now; the kernel from then is already gone.<br> >> >> ><br> >> >> > core.txt said.<br> >> >> ><br> >> >> > panic: mtx_lock_spin: recursed on non-recursive mutex vtbuf @ /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:744<br> >> >> ><br> >> >> > cpuid = 1<br> >> >> > time = 1779437567<br> >> >> > KDB: stack backtrace:<br> >> >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d773e7a0<br> >> >> > vpanic() at vpanic+0x149/frame 0xfffffe00d773e8d0<br> >> >> > panic() at panic+0x43/frame 0xfffffe00d773e930<br> >> >> > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x11b/frame 0xfffffe00d773e970<br> >> >> > vtbuf_flush_mark() at vtbuf_flush_mark+0x82/frame 0xfffffe00d773e9b0<br> >> >> > vtbuf_unmark_on_cross() at vtbuf_unmark_on_cross+0xcc/frame 0xfffffe00d773e9d0<br> >> >> > vtterm_fill() at vtterm_fill+0x27/frame 0xfffffe00d773ea00<br> >> >> > teken_subr_erase_line() at teken_subr_erase_line+0x90/frame 0xfffffe00d773ea20<br> >> >> > teken_state_2() at teken_state_2+0x497/frame 0xfffffe00d773ea40<br> >> >> > teken_input_char() at teken_input_char+0x47/frame 0xfffffe00d773ea60<br> >> >> > teken_input() at teken_input+0x9f/frame 0xfffffe00d773ea90<br> >> >> > termtty_outwakeup() at termtty_outwakeup+0xcf/frame 0xfffffe00d773eb60<br> >> >> > ttydisc_write() at ttydisc_write+0x337/frame 0xfffffe00d773ecd0<br> >> >> > ttydev_write() at ttydev_write+0x13f/frame 0xfffffe00d773ed10<br> >> >> > devfs_write_f() at devfs_write_f+0xf3/frame 0xfffffe00d773ed70<br> >> >> > dofilewrite() at dofilewrite+0x81/frame 0xfffffe00d773edc0<br> >> >> > sys_writev() at sys_writev+0x69/frame 0xfffffe00d773ee00<br> >> >> > amd64_syscall() at amd64_syscall+0x168/frame 0xfffffe00d773ef30<br> >> >> > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00d773ef30<br> >> >> > --- syscall (121, FreeBSD ELF64, writev), rip = 0x82601d5aa, rsp = 0x8207a3408, rbp = 0x8207a3430 ---<br> >> >> > KDB: enter: panic<br> >> >> ><br> >> >> ><br> >> >> > In case it helps, I believe this is file:line as reported by gdb in core.txt:<br> >> >> ><br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/kern_mutex.c:353<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:744<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:864<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:210<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:232<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_core.c:1201<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:121<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken_subr.h:558<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:255<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:284<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/teken/teken.c:317<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/subr_terminal.c:422<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/sys/ttydevsw.h:114<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/tty_ttydisc.c:658<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/tty.c:550<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/fs/devfs/devfs_vnops.c:1980<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/sys/file.h:372<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:565<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:492<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/kern/sys_generic.c:478<br> >> >> > at /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/amd64/amd64/../../kern/subr_syscall.c:193<br> >> >> ><br> >> >> ><br> >> >> > --<br> >> >> > Bjoern A. Zeeb r15:7<br> >> >> ><br> >> >><br> >> >> I think it's probably related to or a regression from<br> >> >> 8db0553ed6d8 ("vt: Clear cut-paste selection if the area intersects<br> >> >> with the filled region")<br> >> >> <a href="https://cgit.freebsd.org/src/commit/?id=8db0553ed6d8636d82a26896237099526b93be19" rel="noreferrer" target="_blank">https://cgit.freebsd.org/src/commit/?id=8db0553ed6d8636d82a26896237099526b93be19</a><br> >> >><br> >> >> which added vtbuf_unmark_on_cross() which is in your panic stack.<br> >> >><br> >> >> I don't know this code but it looks like the mutex is first taken by<br> >> >> teken_input / teken_funcs_pre_input / vtterm_pre_input and then again<br> >> >> by teken_input with your panic stack.<br> >> >><br> >> >> Ryan<br> <br> How is the locking supposed to work in vt_mouse_event anyway?<br> <br> Unsolicited suggestion: require that the vb_lock be held on entry to<br> vtbuf_set_mark, remove the lock acquisition from vtbuf_flush_mark, and<br> make the call path through vt_mouse_event to vtbuf_set_mark and<br> vtbuf_unmark acquire the lock.<br> <br> Ryan<br> </blockquote></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ1Oi8H9Z5U-tvGUA6q-cO-xga%2Bxfa-9C5m%2BK1yXdEJSGiJmKw>
