netdev - Re: iproute2: tc deletion freezes whole server

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: <CANxWus_xL7ztXZpLcc+eMCyysgokHnnAD_vwS0jDEz=Pr-VqXw@mail.gmail.com>
Date:   Wed, 25 Mar 2020 14:33:13 +0100
From:   Václav Zindulka <vaclav.zindulka@...pnet.cz>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: iproute2: tc deletion freezes whole server

On Wed, Mar 25, 2020 at 12:27 PM Václav Zindulka
<vaclav.zindulka@...pnet.cz> wrote:
> > > > > My testing setup consists of approx. 18k tc class rules and approx.
> > > > > 13k tc qdisc rules and was altered only with different interface name....
> > > >
> > > > Please share you tc configurations (tc -s -d qd show dev ..., tc
> > > > -s -d filter show dev...).
> > >
> > > I've placed whole reproducers into repository. Do you need exports of rules too?
> > >
> > > > Also, it would be great if you can provide a minimal reproducer.
> > >
> > > I'm afraid that minor reproducer won't cause the problem. This was
> > > happening mostly on servers with large tc rule setups. I was trying to
> > > create small reproducer for nftables developer many times without
> > > success. I can try to create reproducer as small as possible, but it
> > > may still consist of thousands of rules.
> >
> > Yeah, this problem is probably TC specific, as we clean up from
> > the top qdisc down to each class and each filter.
>
> As I mentioned earlier, this happens even with specific deletion of
> smaller number of rules. Yet I don't oppose it may be caused by tc.
> Just inability to process any packets is strange and I'm not sure it
> is pure tc problem.
>
> > Can you try to reproduce the number of TC classes, for example,
> > down to half, to see if the problem is gone? This could confirm
> > whether it is related to the number of TC classes/filters.
>
> Sure. I'll try to reduce the size of tc rule set and test the problem further.

I've tested it. Delay shortens and extends according to number of
rules to delete.

with approx. 3500 rules it took 2364ms
with approx. 7000 rules it took 5526ms
with approx. 14000 rules it took 11641ms
with approx. 18000 rules it took 13302ms
with approx. 31000 rules it took 22880ms

Do you want me to test it with ifb interface too?