netdev - Re: [PATCH (repost) net-next] sched: add extack for tfilter

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: <Yzillil1skRfQO+C@t14s.localdomain>
Date:   Sat, 1 Oct 2022 17:39:50 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        David Ahern <dsahern@...nel.org>
Subject: Re: [PATCH (repost) net-next] sched: add extack for tfilter_notify

On Sat, Oct 01, 2022 at 11:39:07AM -0700, Cong Wang wrote:
> On Thu, Sep 29, 2022 at 11:35:05AM +0800, Hangbin Liu wrote:
> > In commit 81c7288b170a ("sched: cls: enable verbose logging") Marcelo
> > made cls could log verbose info for offloading failures, which helps
> > improving Open vSwitch debuggability when using flower offloading.
> > 
> > It would also be helpful if "tc monitor" could log this message, as it
> > doesn't require vswitchd log level adjusment. Let's add the extack message
> > in tfilter_notify so the monitor program could receive the failures.
> > e.g.
> > 
> 
> I don't think tc monitor is supposed to carry any error messages, it
> only serves the purpose for monitoring control path events.

But, precisely. In the example Hangbin gave, it is showing why the
entry is not_in_hw. That's still data that belongs to the event that
happened and that can't be queried afterwards even if the user/app
monitoring it want to. Had it failed entirely, I agree, as the control
path never changed.

tc monitor is easier to use than perf probes in some systems. It's not
uncommon to have tc installed but not perf. It's also easier to ask a
customer to run it than explain how to enable the tracepoint and print
ftrace buffer via /sys files, and the output is more meaningful for us
as well: we know exactly which filter triggered the message. The only
other place that we can correlate the filter and the warning, is on
vswitchd log. Which is not easy to read either.

Thanks,
Marcelo