Date: Wed, 22 Apr 2020 19:16:48 +0200 From: peter.blok@bsd4all.org To: d@delphij.net, freebsd-current@freebsd.org Cc: Kristof Provost <kp@FreeBSD.org>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: CFT: if_bridge performance improvements Message-ID: <D3A84D72-8A9B-456E-BCB9-DB8E62274AFA@bsd4all.org> In-Reply-To: <8634ec5c-a509-d2dd-8f5c-31efcbd50340@delphij.net> References: <5377E42E-4C01-4BCC-B934-011AC3448B54@FreeBSD.org> <8e0e2bf1-27cd-1a99-b266-c7223255942f@delphij.net> <BF81FE6C-D4F4-43BA-9DE1-2C6A28A65AF3@FreeBSD.org> <8634ec5c-a509-d2dd-8f5c-31efcbd50340@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Just using pf is enough to provoke this panic. I had the same back =
trace. This patch from Kristof fixed it for me.
diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c
index 373fa096d70..83c453090bb 100644
--- a/sys/net/if_bridge.c
+++ b/sys/net/if_bridge.c
@@ -2529,7 +2529,6 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
OR_PFIL_HOOKED_INET6)) { =
\
if (bridge_pfil(&m, NULL, ifp, =
\
PFIL_IN) !=3D 0 || m =3D=3D NULL) { =
\
- BRIDGE_UNLOCK(sc); =
\
return (NULL); =
\
} =
\
eh =3D mtod(m, struct ether_header *); =
\
> On 22 Apr 2020, at 18:15, Xin Li <delphij@delphij.net> wrote:
>=20
> On 4/22/20 01:45, Kristof Provost wrote:
>> On 22 Apr 2020, at 10:20, Xin Li wrote:
>>> Hi,
>>>=20
>>> On 4/14/20 02:51, Kristof Provost wrote:
>>>> Hi,
>>>>=20
>>>> Thanks to support from The FreeBSD Foundation I=E2=80=99ve been =
able to work on
>>>> improving the throughput of if_bridge.
>>>> It changes the (data path) locking to use the NET_EPOCH =
infrastructure.
>>>> Benchmarking shows substantial improvements (x5 in test setups).
>>>>=20
>>>> This work is ready for wider testing now.
>>>>=20
>>>> It=E2=80=99s under review here: https://reviews.freebsd.org/D24250
>>>>=20
>>>> Patch for CURRENT: https://reviews.freebsd.org/D24250?download=3Dtrue=
>>>> Patches for stable/12:
>>>> https://people.freebsd.org/~kp/if_bridge/stable_12/
>>>>=20
>>>> I=E2=80=99m not currently aware of any panics or issues resulting =
from these
>>>> patches.
>>>=20
>>> I have observed the following panic with latest stable/12 after =
applying
>>> the stable_12 patchset, it appears like a race condition related =
NULL
>>> pointer deference, but I haven't took a deeper look yet.
>>>=20
>>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>>> acting as a router. Please let me know if you need additional
>>> information; I can try -CURRENT as well, but it would take some time =
as
>>> the box is relatively slow (it's a ZFS based system so I can create =
a
>>> separate boot environment for -CURRENT if needed, but that would =
take
>>> some time as I might have to upgrade the packages, should there be =
any
>>> ABI breakages).
>>>=20
>> Thanks for the report. I don=E2=80=99t immediately see how this could =
happen.
>>=20
>> Are you running an L2 firewall on that bridge by any chance? An =
earlier
>> version of the patch had issues with a stray unlock in that code =
path.
>=20
> I don't think I have a L2 firewall (I assume means filtering based on
> MAC address like what can be done with e.g. ipfw? The bridges were
> created on vlan interfaces though, do they count as L2 firewall?), the
> system is using pf with a few NAT rules:
>=20
> $ sudo pfctl -s rules
> anchor "miniupnpd" all
> pass in quick inet6 proto tcp from <myv6> to any flags S/SA keep state
> block drop in quick inet6 proto tcp from ! <myv6> to <myv6> flags S/SA
> block drop in quick proto tcp from any os "Linux" to any port =3D ssh
> pass out on igb6 inet proto tcp from (igb6) to any port =3D domain =
flags
> S/SA keep state queue dns
> pass out on igb6 inet proto udp from (igb6) to any port =3D domain =
keep
> state queue dns
> pass in on igb6 proto tcp from any to (igb6) port =3D http flags S/SA
> modulate state queue(web, ack)
> pass in on igb6 proto tcp from any to (igb6) port =3D https flags S/SA
> modulate state queue(web, ack)
> pass out on igb6 inet proto tcp from (igb6) to any flags S/SA modulate
> state queue bulk
> block drop in quick on igb6 proto tcp from <sshguard> to any port =3D =
ssh
> label "ssh bruteforce"
> block drop in on igb6 from <badhosts> to any
>=20
> Cheers,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D3A84D72-8A9B-456E-BCB9-DB8E62274AFA>