netdev - Re: [Patch net-next v2] net_sched: introduce tracepoint trace_qdisc

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: <CAM_iQpUv+Vw4WsRaPyQxOecDsDQNtDOg6iraXv27uGLPZd01FQ@mail.gmail.com>
Date:   Wed, 14 Jul 2021 21:28:09 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Tonghao Zhang <xiangxia.m.yue@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Qitao Xu <qitao.xu@...edance.com>,
        Cong Wang <cong.wang@...edance.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>
Subject: Re: [Patch net-next v2] net_sched: introduce tracepoint trace_qdisc_enqueue()

On Mon, Jul 12, 2021 at 6:57 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
>
> On Mon, Jul 12, 2021 at 12:45 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> >
> > On Sun, Jul 11, 2021 at 9:41 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> > >
> > > On Mon, Jul 12, 2021 at 12:20 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > >
> > > > On Sun, Jul 11, 2021 at 9:12 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> > > > >
> > > > > On Mon, Jul 12, 2021 at 12:02 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > > > >
> > > > > > On Sun, Jul 11, 2021 at 8:49 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> > > > > > >
> > > > > > > On Mon, Jul 12, 2021 at 11:39 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > > > > > >
> > > > > > > > On Sun, Jul 11, 2021 at 8:36 PM Tonghao Zhang <xiangxia.m.yue@...il.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jul 12, 2021 at 11:23 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > > > > > > > > Sure, in that case a different packet is dropped, once again you
> > > > > > > > > > can trace it with kfree_skb() if you want. What's the problem?
> > > > > > > > > It's ok, but we can make it better. Yunsheng Lin may have explained why?
> > > > > > > >
> > > > > > > > Why it is better to trace dropped packets both in enqueue and in kfree_skb()?
> > > > > > > I mean we can use one tracepoint to know what happened in the queue,
> > > > > > > not necessary to trace enqueue and  kfree_skb()
> > > > > >
> > > > > > This is wrong, packets can be dropped for other reasons too, tracing
> > > > > no matter where the packet is dropped, we should allow user to know
> > > > > whether dropped in the enqueue.  and the
> > > > > what the return value.
> > > >
> > > > Again you can know it by kfree_skb(). And you can not avoid
> > > > kfree_skb() no matter how you change enqueue. So, I don't see your
> > > No, If I know what value returned for specified qdisc , I can know
> > > what happened, not necessarily kfree_skb()
> >
> > This is wrong. You have to trace dropped packets because you
> > need to know when to delete the key (skb address) from the hashtable
> > you use to calculate the latency. You save the key on enqueue and
> > remove it on both dequeue and kfree_skb, the only difference is you
> No, we can set the timestamp or cb in  skb in enqueue and check them in dequeue.
> we may not use the hashtable.

Are you sure this is safe?? How do you ensure we have enough space
in skb->cb[]? More importantly, why do we even modify skb in tracepoint?

> If we use hashtable, we still can check the return value, save them to
> hashtable or not.

How many times do I have to repeat the return value of enqueue is not
sufficient even if you trace it? Can't you just look at codel_dequeue()
and tell me how a drop at dequeue can be reflected to enqueue?

Thanks.