netdev - Re: RFH, where did I go wrong?

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] [day] [month] [year] [list]

Message-ID: <d0755144-c038-8332-1084-b62cc9c6499@tarent.de>
Date:   Tue, 13 Sep 2022 20:37:53 +0200 (CEST)
From:   Thorsten Glaser <t.glaser@...ent.de>
To:     Haye.Haehne@...ekom.de
cc:     netdev@...r.kernel.org
Subject: Re: RFH, where did I go wrong?

Hi Haye,

> I could retest the crash scenario of the qdisc, it occurs in the
> context of tc change /reconfiguration. When I define a static qdisc
> setup, the iperf udp stream with 50M (qdisc rate 20M) is stable.

thanks. (By the way, gstscream/scripts/sysctl.sh from SCReAM indeed
allows me to fill the queue fully with locally originating traffic.)

> So you should indeed take a deeper look into the processing during
> reconfiguration.

I did have a look. I could not reproduce the crash just with changing
qdisc things, not even a lot of times (100 Hz).

I tried:

$ sudo mksh -c 'qq=0; while sleep 0.01; do
	if (( ++qq == 500 )); then lim=50; qq=0; else lim=10240; fi
	tc qdisc change dev eth1 handle 1: janz rate 20mbit limit $lim
    done'

(changing the qdisc 100 times a second; every five seconds the limit
goes WAY down, to show the dropping code isn’t the cause either)

3x $ iperf -u -c 10.82.222.129 -t 600 -b 40M -S 0x01

(for some reason, IPv6 did not work with iperf for me)

$ sudo mksh -c 'while sleep 0.25; do tc -s qdisc show dev eth1 | fgrep backlog; done'

(for monitoring)

Evidently, what I’m changing, or how often, isn’t sufficient to trigger
the issue. Let’s phone tomorrow to try to figure out a good reproducer,
I might need to use jenscli with the data rate pattern you use, which is
less self-contained than I would normally prefer in a reproducer…

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************