netdev - Re: Question: Patch:("net: sched: cbq: dont intepret cls results when asked to drop") may be not bug for branch LTS 5.10

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: <Y8lxDBaULPzZMIS1@dcaratti.users.ipa.redhat.com>
Date:   Thu, 19 Jan 2023 17:34:20 +0100
From:   Davide Caratti <dcaratti@...hat.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Kyle Zeng <zengyhkyle@...il.com>,
        shaozhengchao <shaozhengchao@...wei.com>,
        David Miller <davem@...emloft.net>,
        Sasha Levin <sashal@...nel.org>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Question: Patch:("net: sched: cbq: dont intepret cls results
 when asked to drop") may be not bug for branch LTS 5.10

On Wed, Jan 18, 2023 at 12:00:57PM -0500, Jamal Hadi Salim wrote:

> On Wed, Jan 18, 2023 at 11:00 AM Davide Caratti <dcaratti@...hat.com> wrote:

[...] 

> > With HTB, CBQ, DRR, HFSC, QFQ and ATM it's possible that the TC classifier
> > selects a traffic class for a given packet and writes that pointer in 'res.class'.
> 
> It's their choice of how to implement.

[...] 

> If all goes well, it is a good pointer.

Oh, probably now I see - the assignment in .bind_class() does the magic.

[...]

> > well, the implementation of "goto_chain" actually abuses tcf_result:
> > since it's going to pass the packet to another classifier, it
> > temporarily stores a handle to the next filter in the tcf_result -
> > instead of passing it through the stack. That is not a problem, unless
> > a packet hits the max_reclassify_loop and a CBQ qdisc that dereferences
> > 'res.class' even with a packet drop :)
> >
> 
> The rule is tcf_results should be returning the results and execution
> state to the caller. The goto_chain maybe ok in this case.

it looks ok because the chain is another classifier that re-writes tcf_result
with its own res.class + res.classid. Maybe we should assess what happens
when no classifier matches the packet after a goto_chain (i.e. let's check
if res.class still keeps a pointer to struct tcf_proto). However, tcf_classify()
returns -1 (TC_ACT_UNSPECT) in this case: CBQ and other qdiscs already
ignore tcf_result here.
 
> BTW, I did create a patch initially when this issue surfaced but we
> needed to get something to net first. See attached. The proper way to
> do this is to have the small surgery that returns the errcode instead
> of verdict code and store TC_ACT_XXX in tcf_result (in place of errcode).

my 2 cents: I really would like to see a different skb drop reason for these
packets (currently they are accounted as SKB_DROP_REASON_QDISC_DROP like
regular qdisc drops [1][2]). 

thanks!

[1] https://elixir.bootlin.com/linux/latest/source/net/core/dev.c#L3886
[2] https://lore.kernel.org/netdev/Yt2CIl7iCoahCPoU@pop-os.localdomain/ 

-- 
davide