Date: Sun, 01 Feb 2015 09:55:10 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197059] network locks up with IPv6 udp traffic Message-ID: <bug-197059-2472-56f0f2IQCr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-197059-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-197059-2472@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=197059 Robert Watson <rwatson@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rwatson@FreeBSD.org --- Comment #2 from Robert Watson <rwatson@FreeBSD.org> --- Some notes form an e-mail from myself to Andrey about this problem: Basically, the general rule, with respect to lock order, is that the network-stack input path can call the output path (e.g., inbound TCP segment triggers an immediate send of a TCP ACK), but you can't directly call in the other direction or you would violate the lock order. In this sort of situation, the output path needs to reinject packets via the netisr, rather than directly invoking the input path. This is how we handle, for example, routing-socket packets triggered by send events -- they are enqueued to the netisr for processing asynchronously, providing a context where transmit-pathj locks can be safely acquired. (Basically, pfctlinput() is never safe to call from the transmit path.) -- You are receiving this mail because: You are on the CC list for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-197059-2472-56f0f2IQCr>