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

Message-ID: <CAM0EoMmwFoAtniCY0WaM6T-9MWoAAyk+MmYTO12hyuOGD4wpSA@mail.gmail.com>
Date:   Mon, 23 Jan 2023 14:50:00 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Davide Caratti <dcaratti@...hat.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 Thu, Jan 19, 2023 at 11:34 AM Davide Caratti <dcaratti@...hat.com> wrote:
>
> 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.
>

Yes.

> > 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]).
>

I should make it clear, that is not the patch that needs to move
forward; it was just
a quick experiment.
I think we can add a lot more fine grained details on the result such
as what you
described above.
I am pre-occupied elsewhere but will get it to it probably by coming weekend..

cheers,
jamal