linux-kernel - Re: [PATCH v3] net/bridge: Optimizing read-write locks in ebtables.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iLoBYjMmot=6e_WJrtEhcAzWikU2eV0eQExHPj7+ObGKA@mail.gmail.com>
Date: Tue, 24 Sep 2024 15:46:17 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: yushengjin <yushengjin@...ontech.com>, pablo@...filter.org, kadlec@...filter.org, 
	roopa@...dia.com, razor@...ckwall.org, davem@...emloft.net, kuba@...nel.org, 
	pabeni@...hat.com, netfilter-devel@...r.kernel.org, coreteam@...filter.org, 
	bridge@...ts.linux.dev, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] net/bridge: Optimizing read-write locks in ebtables.c

On Tue, Sep 24, 2024 at 3:33 PM Stephen Hemminger
<stephen@...workplumber.org> wrote:
>
> On Tue, 24 Sep 2024 17:09:06 +0800
> yushengjin <yushengjin@...ontech.com> wrote:
>
> > When conducting WRK testing, the CPU usage rate of the testing machine was
> > 100%. forwarding through a bridge, if the network load is too high, it may
> > cause abnormal load on the ebt_do_table of the kernel ebtable module, leading
> > to excessive soft interrupts and sometimes even directly causing CPU soft
> > deadlocks.
> >
> > After analysis, it was found that the code of ebtables had not been optimized
> > for a long time, and the read-write locks inside still existed. However, other
> > arp/ip/ip6 tables had already been optimized a lot, and performance bottlenecks
> > in read-write locks had been discovered a long time ago.
> >
> > Ref link: https://lore.kernel.org/lkml/20090428092411.5331c4a1@nehalam/
> >
> > So I referred to arp/ip/ip6 modification methods to optimize the read-write
> > lock in ebtables.c.
>
> What about doing RCU instead, faster and safer.

Safer ? How so ?

Stephen, we have used this stuff already in other netfilter components
since 2011

No performance issue at all.

Honestly, this old link (
https://lore.kernel.org/lkml/20090428092411.5331c4a1@nehalam/ ) is
quite confusing,
please yushengjin do not include it next time, or we will get outdated feedback.

Instead, point to the real useful commit :

commit 7f5c6d4f665bb57a19a34ce1fb16cc708c04f219
    netfilter: get rid of atomic ops in fast path

This is the useful commit, because this ebtable patch simply adopts
the solution already used in iptables.

And please compile your patch, and boot it, test it before sending it again.