netdev - Re: problems with hfsc since 5.10.238-patches in sched

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: <c992d237-5ad2-2970-d275-ea1cdfc15ac3@is-kassel.org>
Date: Tue, 12 Aug 2025 09:23:44 +0200
From: lkml-xx-15438@...werbittewas.de
To: jhs@...atatu.com
Cc: netdev@...r.kernel.org, xiyou.wangcong@...il.com, jiri@...nulli.us,
        victor@...atatu.com, pctammela@...atatu.com
Subject: Re: problems with hfsc since 5.10.238-patches in sched_hfsc.c

hi,

thank you for spending time on this problem.

we followed your suggestion to try the actual kernel (we've tried it
before without success), but now with clean build from scratch instead
of using the old tree with incremental patches and voila: we can't
reproduce the behaviour any more!

sorry for that. if there will be ever again such a problem, we will
first try to make a clean build before asking for help.

best regards

x.

Am 11.08.25 um 06:44 schrieb Jamal Hadi Salim:
> Hi,
> 
> On Sat, Aug 9, 2025 at 4:13 PM <lkml-xx-15438@...werbittewas.de> wrote:
>>
>> hi.
>>
>> hopefully the right list for this problem, else please tell me the right
>> one.
>>
>> Problem:
>> after updating to 5.10.238 (manually compiled) hfsc is malfunctioning here.
>> after a long time with noch changes and no problems, most packages are
>> dropped without notice.
>>
>> after some tries we've identified the patches
>>
>> - https://lore.kernel.org/all/20250425220710.3964791-3-victor@mojatatu.com/
>>
>> and
>>
>> -
>> https://lore.kernel.org/all/20250522181448.1439717-2-pctammela@mojatatu.com/
>>
>> which seems to lead to misbehaviour.
>>
>>
>> by changing the line in hfsc_enqueue()
>>
>> "if (first && !cl_in_el_or_vttree(cl)) {"
>>
>> back to
>>
>> "if (first) {"
>>
>> all went well again.
>>
>>
>> if it matters: we're using a simple net-ns-container for
>> forwarding/scheduling the local dsl-line
>>
>>
>> maybe we're using a config of hfsc, which is not ok (but we're doing
>> this over several years)
>>
>> our hfsc-init is like:
>>
>>
>> /sbin/tc qdisc add dev eth0 root handle 1: hfsc default 14
>>
>> /sbin/tc class add dev eth0 parent 1: classid 1:10 hfsc ls m2 36000kbit
>> ul m2 36000kbit
>>
>> /sbin/tc class add dev eth0 parent 1:10 classid 1:14 hfsc ls m1
>> 36000kbit d 10000ms m2 30000kbit ul m1 30000kbit d 10000ms m2 25000kbit
>>
>> (normally there are further lines, but above calls are sufficant to
>> either forward the packets before .238 or let them drop with .238 or
>> later. we're using an old tc (iproute2-5.11.0) on this system.
>>
>>
>> so, it would be nice, if someone can tell us, why the above
>> hfsc-init-calls are bad, or if they're ok and the changes in 5.10.238
>> have side-effects, which lead to this behaviour.
>>
>>
> 
> Please retry with the latest 5.10.xx since it seems some patches were
> left out in the backport. And if that still exhibits this problem try
> the latest  6.17 net tree because it will help isolate if the issue is
> only with 5.10.x.
> If the problem persists please share your script/netns setup. And in
> the future please Cc the stakeholders. It makes it easier to help.
> For the record, trying what you just described with kernel 5.10.238
> and iproute2 5.11.0 didnt recreate the issue. Basically:
> Creating a netns, running your commands, pings from the netns and
> netcat.. It all worked fine, no drops.
> 
> cheers,
> jamal
> 
> 
> 
> 
>> thanks a lot.
>>
>> regards
>>
>> x.
>>