netdev - Re: [PATCH net-next RFC v1 0/3] net: sched: refactor qdisc drop reasons into dedicated tracepoint

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: <877bsr1l1h.fsf@toke.dk>
Date: Thu, 05 Feb 2026 12:34:18 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Jesper Dangaard Brouer <hawk@...nel.org>, Jakub Kicinski
 <kuba@...nel.org>, Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Paolo
 Abeni <pabeni@...hat.com>, bpf@...r.kernel.org, horms@...nel.org,
 jiri@...nulli.us, edumazet@...gle.com, xiyou.wangcong@...il.com,
 jhs@...atatu.com, carges@...udflare.com, kernel-team@...udflare.com,
 Antoine Tenart <atenart@...hat.com>
Subject: Re: [PATCH net-next RFC v1 0/3] net: sched: refactor qdisc drop
 reasons into dedicated tracepoint

Jesper Dangaard Brouer <hawk@...nel.org> writes:

> On 05/02/2026 04.04, Jakub Kicinski wrote:
>> On Wed, 04 Feb 2026 18:02:49 +0100 Jesper Dangaard Brouer wrote:
>>> RFC: Seeking feedback on this refactoring approach.
>>>
>>> This series refactors qdisc drop reason handling by introducing a dedicated
>>> enum qdisc_drop_reason and trace_qdisc_drop tracepoint, providing qdisc
>>> layer drop diagnostics with direct qdisc context visibility.
>> 
>> I like this!
>
> Awesome, then I will continue in this direction :-)
>
>> It will presumably require existing users to migrate over
>> but sooner we do it the fewer users that have to move?
>
> I agree. Existing users will loose some details, but the patchset
> results in fallback to SKB_DROP_REASON_QDISC_DROP as a drop reason,
> which existing tools/users will still handle.
> (The more specific drop reason is now avail via trace_qdisc_drop).
>
> Eric and Toke is this acceptable for your users?

I like it! My only concern is that drop monitor tools will see two
events for each qdisc drop. I guess that could be relatively
straight-forwardly deduplicated in the tool, though? +Antoine who works
on Retis to give him a chance to complain if not :)

> In patch 1/3 I kept the qdisc "name" as part of the enum for FQ and
> CAKE. IMHO this should be changed for next patchset, but I offer you the
> chance to review and suggest generic naming (else I will choose).

You mean you'd just name it something like QDISC_DROP_FLOOD_PROTECTION
instead of QDISC_DROP_CAKE_FLOOD? No strong objections to that...

-Toke