https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197059
Robert Watson <rwat...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rwat...@freebsd.org
--- Comment #2 from Robert Watson <rwat...@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.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
