#
324116 |
|
30-Sep-2017 |
kp |
MFC r323864
bridge: Set module version
This ensures that the loader will not load the module if it's also built in to the kernel.
PR: 220860 Submitted by: Eugene Grosbein <eugen@freebsd.org>
|
#
313066 |
|
01-Feb-2017 |
kp |
MFC 312782
bridge: Release the bridge lock when calling bridge_set_ifcap()
This calls ioctl() handlers for the different interfaces in the bridge. These handlers expect to get called in an ioctl context where it's safe for them to sleep. We may not sleep with the bridge lock held.
However, we still need to protect the interface list, to ensure it doesn't get changed while we iterate over it. Use BRIDGE_XLOCK(), which prevents bridge members from being removed. Adding bridge members is safe, because it uses LIST_INSERT_HEAD().
This caused panics when adding xen interfaces to a bridge.
PR: 216304 Reviewed by: ae Sponsored by: RootBSD Differential Revision: https://reviews.freebsd.org/D9290
|
#
306594 |
|
02-Oct-2016 |
kp |
MFC r306289:
bridge: Fix fragment handling and memory leak
Fragmented UDP and ICMP packets were corrupted if a firewall with reassembling feature (like pf'scrub) is enabled on the bridge. This patch fixes corrupted packet problem and the panic (triggered easly with low RAM) as explain in PR 185633.
bridge_pfil and bridge_fragment relationship:
bridge_pfil() receive (IN direction) packets and sent it to the firewall The firewall can be configured for reassembling fragmented packet (like pf'scrubing) in one mbuf chain when bridge_pfil() need to send this reassembled packet to the outgoing interface, it needs to re-fragment it by using bridge_fragment() bridge_fragment() had to split this mbuf (using ip_fragment) first then had to M_PREPEND each packet in the mbuf chain for adding Ethernet header.
But M_PREPEND can sometime create a new mbuf on the begining of the mbuf chain, then the "main" pointer of this mbuf chain should be updated and this case is tottaly forgotten. The original bridge_fragment code (Revision 158140, 2006 April 29) came from OpenBSD, and the call to bridge_enqueue was embedded. But on FreeBSD, bridge_enqueue() is done after bridge_fragment(), then the original OpenBSD code can't work as-it of FreeBSD.
PR: 185633 Submitted by: Olivier Cochard-Labbé
|
#
304427 |
|
18-Aug-2016 |
mav |
MFC r303009: Negotiate/disable TXCSUM_IPV6 same as TXCSUM.
|
#
285016 |
|
01-Jul-2015 |
kp |
MFC r284348: Fix panic when adding vtnet interfaces to a bridge
vtnet interfaces are always in promiscuous mode (at least if the VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This confused the bridge code. Instead we now accept all enable/disable promiscuous commands (and always keep IFF_PROMISC set).
There are also two issues with the if_bridge error handling.
If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to disable promiscuous mode on the interface. That runs into an assert, because promiscuous mode was never set in the first place. (That's the panic reported in PR 200210.) We can only unset promiscuous mode if the interface actually is promiscuous. This goes against the reference counting done by if_promisc(), but only the first/last if_promic() calls can actually fail, so this is safe.
A second issue is a double free of bif. It's already freed by bridge_delete_member().
PR: 200210
|
#
285016 |
|
01-Jul-2015 |
kp |
MFC r284348: Fix panic when adding vtnet interfaces to a bridge
vtnet interfaces are always in promiscuous mode (at least if the VIRTIO_NET_F_CTRL_RX feature is not negotiated with the host). if_promisc() on a vtnet interface returned ENOTSUP although it has IFF_PROMISC set. This confused the bridge code. Instead we now accept all enable/disable promiscuous commands (and always keep IFF_PROMISC set).
There are also two issues with the if_bridge error handling.
If if_promisc() fails it uses bridge_delete_member() to clean up. This tries to disable promiscuous mode on the interface. That runs into an assert, because promiscuous mode was never set in the first place. (That's the panic reported in PR 200210.) We can only unset promiscuous mode if the interface actually is promiscuous. This goes against the reference counting done by if_promisc(), but only the first/last if_promic() calls can actually fail, so this is safe.
A second issue is a double free of bif. It's already freed by bridge_delete_member().
PR: 200210
|