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: <87v7gbz1ru.fsf@toke.dk>
Date: Thu, 05 Feb 2026 15:46:29 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Antoine Tenart <atenart@...hat.com>
Cc: Jesper Dangaard Brouer <hawk@...nel.org>, Jakub Kicinski
 <kuba@...nel.org>, Eric Dumazet <eric.dumazet@...il.com>,
 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

Antoine Tenart <atenart@...hat.com> writes:

> On Thu, Feb 05, 2026 at 12:34:18PM +0100, Toke Høiland-Jørgensen wrote:
>> Jesper Dangaard Brouer <hawk@...nel.org> writes:
>> > On 05/02/2026 04.04, Jakub Kicinski wrote:
>> >
>> >> 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 :)
>
> Thanks for the heads up. We'll have to add support for the new enum
> (pretty straightforward), other than that things should just work.
>
> I'm wondering why not using the drop reason subsys logic to combine the
> qdisc specific enum while not conflicting with drop reasons and allowing
> to inject the qdisc reasons into drop reason enabled helpers as well?

See this prior discussion for how the proposal came to be:

https://lore.kernel.org/all/6be17a08-f8aa-4f91-9bd0-d9e1f0a92d90@kernel.org/

Basically, figuring out which qdisc a drop came from is not possible
with the current drop_reason code.

So it's not just new drop reasons, it's a separate tracepoint with more
information available (qdisc handle, name, etc). So you'll get two
events for qdisc drops with this series (from patch 1):

+		trace_qdisc_drop(q, txq, dev, skb, reason);
+		kfree_skb_reason(skb, SKB_DROP_REASON_QDISC_DROP);

-Toke