From nobody Fri Jun 12 00:15:03 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gc0Qh3Hfcz6gydv for ; Fri, 12 Jun 2026 00:15:24 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gc0Qf5Qr6z48W2 for ; Fri, 12 Jun 2026 00:15:22 +0000 (UTC) (envelope-from ray@ddteam.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 209.85.208.49 is neither permitted nor denied by domain of ray@ddteam.net) smtp.mailfrom=ray@ddteam.net; arc=pass ("google.com:s=arc-20240605:i=1") Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-68c3421b009so2327523a12.1 for ; Thu, 11 Jun 2026 17:15:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781223320; cv=none; d=google.com; s=arc-20240605; b=Zo2xpL2xgOXCj13xHb9hwjmoKqzVwuVfotrsSwTU9Chu8GKdTQUgIwvm9NRF0paka7 +IPBwIOwN2nUHf4BZOyvNhPws4Q91KMzeaIvgaSp6sZ6+XinISzM1a9fMDEKw5sps5mo yi66OTNtmxpitRRZsBm+ohpbv3XX3Q+puMdldBRtXb9KDwJHOwyOhIvoiMAZe2a+yTSp YIPCYPJW4WMk/PixTrCDWpvsmCVOb4d1BzkACpo3NdMo3067H+baFZHZE9ajCI2eMpa4 KVFqBBCfDPHEo4kc3TxK3YkkkfjS7yWny9MfL8+37wyYRgujvemonMSfofjzngDDgEZF 6h4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version; bh=vkek1iVJwlpdK7U4U5UNVfmOe7CfA+wPVxIoyuiBAYk=; fh=aYZnDOlWFwxeFwgmkU52DPrZjeVxZ7K6WMytT23p/t8=; b=bX0wO7nNsAym0PZoq+VBLNIi9Kb2VCvdRhR5QTQKeQlYxRqpf5iYf1KW/R/EzXgBFU pIu4kSFPd/DpYg/sPM9jt428f9WCh2EoWiLCZqtTp7LjnVIlAZZA6imdaP3z6mtljX6h 4qXTgeMtmaYnE4nKuDZEgDTRZ5nikZ6Re1DK+HX11BAmcRnRBCbp1AD3n6fV2mc5Hyhq g3JRP40uc6qNYZxlXMH64M2wiB53qIxrIGApva52O8A4CWG+91wZEFpZGuDuOLrMceqo wIuyKhv/ao//sI3yplT7xRXBKdQYJ/ijeMYuBdXXPXTV3GoJFxB4jJz1awuBoNtTr5wJ KImg==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781223320; x=1781828120; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vkek1iVJwlpdK7U4U5UNVfmOe7CfA+wPVxIoyuiBAYk=; b=YXVRtLp9anqKZ3cv80gal2PF2kOCnn4Bu31dHS+AoQ9479CqelWLTnv7u9A5YtnVRw tZ7VXfeIGRUJ/HFN0CgjgcOUlq0j38mPlouUIZQqw2VcGaLQDh8CTdW5IxSQ0wIC7ZmR TdiSVg8+K7hjHdGOK+eDcCtipyCuBvbpfUgKjZymPg6UpA4c2hjk4OFv5hbvHBlzUezt w5cGtaT6KtYfqYKkJhEtq8DCMiL7jiseg+wscMCNfI6O90rZYLbYw2EV7RHBWTM6bsLn C7gnRZI/LEjpW7XtMP9TKyHesg4rXGjrXLkDLDXCjZpataJZasp/vDQmv0+QsL2OLmNl ob4g== X-Forwarded-Encrypted: i=1; AFNElJ9nAGY7nn/Y4XZ2cVjd9BRs8pZCBKG3Peo/bGVCXzgyaDVgkUBQ79+60CKpM2FaKbKpgisnIbcu@freebsd.org X-Gm-Message-State: AOJu0Yx+fdaCMbfQQX9f26v9V9WQ62TUB9uhJ8TWRaNTsFXsAn7OFHYs slrfzM5VOV+Eaprb1/ed/2ea+j//iMaWvxjincCWr0bzhkM9MCv0Mg1VPnnx5uhBbRXjm1V25Lk BnuLBqTd0dtzTlpHQrzvIijCW0AvzilecB7wcqfkR++eks8u9+/1UMg== X-Gm-Gg: Acq92OGLAMJk2yWnUrwhHlM093pc10eS/fC50QK0Nnu+CMCZ2Leeeet2SfsDmngR5dC 2njaS9/NDB0oo25z7mWM1FmMGM0LXWBnDnEFRQxsvwXjO76yvNkich7FqHCv6/Rcyk8Kgxgih3M hAi9YKLQOa8T65JTvyvhU2QgdHFZlXtROj3f31WjeyqnrK4tTjQrPuCtmbKuYk4oA3jmTj50dxA QUoaZx+mIkFt8lDnMvxDVQu7cEX8wYywzoTmJzVxvlrKSSEsBXeSsN7ym5ArlMMhLOw6HuEiX/Z oJsAk/pO X-Received: by 2002:a17:906:ef0d:b0:bee:a39b:ab7b with SMTP id a640c23a62f3a-bfde5ac490amr42286466b.31.1781223319901; Thu, 11 Jun 2026 17:15:19 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: In-Reply-To: From: Aleksandr Rybalko Date: Fri, 12 Jun 2026 03:15:03 +0300 X-Gm-Features: AVVi8CdeH7BxGXMtHEsIVxukteXLvRLur68axV_L8DireBsQIVsiTWTBqer8wNU Message-ID: Subject: Re: panic: mtx_lock_spin: recursed on non-recursive mutex vtbuf @ .. To: Ryan Libby Cc: Adrian Chadd , "Bjoern A. Zeeb" , current@freebsd.org, imp@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003fa4030654035fd2" X-Spamd-Result: default: False [-3.59 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.89)[-0.892]; FORGED_SENDER(0.30)[ray@freebsd.org,ray@ddteam.net]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.49:from]; FREEFALL_USER(0.00)[ray]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.49:from]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[ray@freebsd.org,ray@ddteam.net]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gc0Qf5Qr6z48W2 --0000000000003fa4030654035fd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fixed with mtx_owned(9) test yet. See https://github.com/freebsd/freebsd-src/commit/1f68ca5802db91bd9725bcdbf5593= 2e104dbe95d Thanks! =D1=81=D0=B1, 6 =D1=87=D0=B5=D1=80=D0=B2. 2026=E2=80=AF=D1=80. =D0=BE 03:17= Ryan Libby =D0=BF=D0=B8=D1=88=D0=B5: > On Tue, Jun 2, 2026 at 3:01=E2=80=AFPM Aleksandr Rybalko wrote: > > > > Hey, Adrian! > > > > Know why, but working on a fix yet. > > > > Thanks! > > > > =D0=B2=D1=82, 2 =D1=87=D0=B5=D1=80=D0=B2. 2026=E2=80=AF=D1=80. =D0=BE 2= 0:01 Adrian Chadd =D0=BF=D0=B8=D1=88=D0=B5: > >> > >> 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 > wrote: > >> > > >> > Hey guys! > >> > > >> > Yeah, it seems my. > >> > I will look into it today. > >> > > >> > Thanks! > >> > > >> > =D0=BF=D1=82, 22 =D1=82=D1=80=D0=B0=D0=B2. 2026=E2=80=AF=D1=80. =D0= =BE 18:35 Ryan Libby =D0=BF=D0=B8=D1=88=D0=B5: > >> >> > >> >> On Fri, May 22, 2026 at 1:46=E2=80=AFAM Bjoern A. Zeeb > >> >> 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 t= o > 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:74= 4 > >> >> > > >> >> > cpuid =3D 1 > >> >> > time =3D 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 =3D 0x82601d5aa, rs= p =3D > 0x8207a3408, rbp =3D 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:74= 4 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:86= 4 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:21= 0 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:23= 2 > >> >> > at > /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_core.c:1= 201 > >> >> > 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_vno= ps.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=3D8db0553ed6d8636d82a268962370995= 26b93be19 > >> >> > >> >> 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 b= y > >> >> teken_input / teken_funcs_pre_input / vtterm_pre_input and then aga= in > >> >> 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 > --0000000000003fa4030654035fd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D1=81=D0=B1, 6 =D1=87=D0=B5= =D1=80=D0=B2. 2026=E2=80=AF=D1=80. =D0=BE 03:17 Ryan Libby <rlibby@freebsd.org> =D0=BF=D0=B8=D1=88=D0= =B5:
On Tue, Jun= 2, 2026 at 3:01=E2=80=AFPM Aleksandr Rybalko <ray@freebsd.org> wrote:
>
> Hey, Adrian!
>
> Know why, but working on a fix yet.
>
> Thanks!
>
> =D0=B2=D1=82, 2 =D1=87=D0=B5=D1=80=D0=B2. 2026=E2=80=AF=D1=80. =D0=BE = 20:01 Adrian Chadd <adrian@freebsd.org> =D0=BF=D0=B8=D1=88=D0=B5:
>>
>> 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!
>> >
>> > =D0=BF=D1=82, 22 =D1=82=D1=80=D0=B0=D0=B2. 2026=E2=80=AF=D1= =80. =D0=BE 18:35 Ryan Libby <rlibby@freebsd.org> =D0=BF=D0=B8=D1=88=D0=B5:
>> >>
>> >> On Fri, May 22, 2026 at 1:46=E2=80=AFAM Bjoern A. Zeeb >> >> <bzeeb-lists@lists.zabbadoz.net> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > I was using the mouse in tmux on v1 when everying st= opped.
>> >> > 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 al= ready gone.
>> >> >
>> >> > core.txt said.
>> >> >
>> >> > panic: mtx_lock_spin: recursed on non-recursive mute= x vtbuf @ /usr/home/test/Sources/git/FreeBSD/freebsd-src.git/sys/dev/vt/vt_= buf.c:744
>> >> >
>> >> > cpuid =3D 1
>> >> > time =3D 1779437567
>> >> > KDB: stack backtrace:
>> >> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2= b/frame 0xfffffe00d773e7a0
>> >> > vpanic() at vpanic+0x149/frame 0xfffffe00d773e8d0 >> >> > panic() at panic+0x43/frame 0xfffffe00d773e930
>> >> > __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x1= 1b/frame 0xfffffe00d773e970
>> >> > vtbuf_flush_mark() at vtbuf_flush_mark+0x82/frame 0x= fffffe00d773e9b0
>> >> > vtbuf_unmark_on_cross() at vtbuf_unmark_on_cross+0xc= c/frame 0xfffffe00d773e9d0
>> >> > vtterm_fill() at vtterm_fill+0x27/frame 0xfffffe00d7= 73ea00
>> >> > teken_subr_erase_line() at teken_subr_erase_line+0x9= 0/frame 0xfffffe00d773ea20
>> >> > teken_state_2() at teken_state_2+0x497/frame 0xfffff= e00d773ea40
>> >> > teken_input_char() at teken_input_char+0x47/frame 0x= fffffe00d773ea60
>> >> > teken_input() at teken_input+0x9f/frame 0xfffffe00d7= 73ea90
>> >> > termtty_outwakeup() at termtty_outwakeup+0xcf/frame = 0xfffffe00d773eb60
>> >> > ttydisc_write() at ttydisc_write+0x337/frame 0xfffff= e00d773ecd0
>> >> > ttydev_write() at ttydev_write+0x13f/frame 0xfffffe0= 0d773ed10
>> >> > devfs_write_f() at devfs_write_f+0xf3/frame 0xfffffe= 00d773ed70
>> >> > dofilewrite() at dofilewrite+0x81/frame 0xfffffe00d7= 73edc0
>> >> > sys_writev() at sys_writev+0x69/frame 0xfffffe00d773= ee00
>> >> > amd64_syscall() at amd64_syscall+0x168/frame 0xfffff= e00d773ef30
>> >> > fast_syscall_common() at fast_syscall_common+0xf8/fr= ame 0xfffffe00d773ef30
>> >> > --- syscall (121, FreeBSD ELF64, writev), rip =3D 0x= 82601d5aa, rsp =3D 0x8207a3408, rbp =3D 0x8207a3430 ---
>> >> > KDB: enter: panic
>> >> >
>> >> >
>> >> > In case it helps, I believe this is file:line as rep= orted by gdb in core.txt:
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/kern/kern_mutex.c:353
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:744
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:864
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:210
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/dev/vt/vt_buf.c:232
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/dev/vt/vt_core.c:1201
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/teken/teken.c:121
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/teken/teken_subr.h:558
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/teken/teken.c:255
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/teken/teken.c:284
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/teken/teken.c:317
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/kern/subr_terminal.c:422
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/sys/ttydevsw.h:114
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/kern/tty_ttydisc.c:658
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/kern/tty.c:550
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/fs/devfs/devfs_vnops.c:1980
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/sys/file.h:372
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/kern/sys_generic.c:565
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/kern/sys_generic.c:492
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/kern/sys_generic.c:478
>> >> >=C2=A0 =C2=A0 =C2=A0 at /usr/home/test/Sources/git/Fr= eeBSD/freebsd-src.git/sys/amd64/amd64/../../kern/subr_syscall.c:193
>> >> >
>> >> >
>> >> > --
>> >> > Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0r15: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=3D8db0553ed6d8636d82a26896237099526= b93be19
>> >>
>> >> which added vtbuf_unmark_on_cross() which is in your pani= c 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 an= d 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
--0000000000003fa4030654035fd2--