On 08/08/15 07:49, Julien Charbon wrote: > On 08/08/15 05:25, Mark Johnston wrote: >> On Fri, Aug 07, 2015 at 08:04:01PM -0500, Larry Rosenman wrote: >>> Trying to debug TimeWarner IPV6 to my HE.NET tunnel, and running traceroute6, >>> got the following panic: >>> >>> borg.lerctr.org dumped core - see /var/crash/vmcore.0 >>> >>> Fri Aug 7 19:58:40 CDT 2015 >>> >>> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #32 r286338: Wed Aug 5 15:57:55 CDT 2015 root_at_borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >>> >>> panic: Lock tcp not read locked _at_ /usr/src/sys/netinet/tcp_subr.c:1189 >>> >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and you are >>> welcome to change it and/or distribute copies of it under certain conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for details. >>> This GDB was configured as "amd64-marcel-freebsd"... >>> >>> Unread portion of the kernel message buffer: >>> panic: Lock tcp not read locked _at_ /usr/src/sys/netinet/tcp_subr.c:1189 >> >> This appears to be fallout from r286227: the tcpinfo lock assertion in >> tcp_notify() is too strong, since tcp_notify() can still be called from >> c with the tcpinfo write lock held. > > Nice catch, I agree these tcpinfo lock assertion are too strong. I am > fixing and testing that as in top of tcp_notify() and tcp_drop(), you > also need to update also tcp_close() and tcp_detach(). I pushed a fix in r286443. I am checking if other paths have the same issue of kernel assertions being too strict with INP_INFO read/write lock checks. Thanks for the detailed report and patch proposal. -- Julien
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC