netdev - Re: [PATCH v2 net-next 3/6] sfc: optional logging of TC offload errors

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: <20220928113253.1823c7e1@kernel.org>
Date:   Wed, 28 Sep 2022 11:32:53 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Edward Cree <ecree.xilinx@...il.com>
Cc:     netdev@...r.kernel.org, linux-net-drivers@....com,
        davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
        habetsm.xilinx@...il.com
Subject: Re: [PATCH v2 net-next 3/6] sfc: optional logging of TC offload
 errors

On Wed, 28 Sep 2022 19:17:51 +0100 Edward Cree wrote:
> > Because extack does not work somehow?  
> 
> Last I checked, flow rules coming from an indirect binding to a tunnel
>  netdev did not report the hw driver's extack (or even rc) back to the
>  user.
> Also, extack can only contain fixed strings (netlink.h: "/* Currently
>  string formatting is not supported (due to the lack of an output
>  buffer.) */") which was a real problem for us.
> 
> > Somehow you limitations are harder to debug that everyone else's so you
> > need a private flag? :/  
> 
> It's not about debugging the driver, it's about communicating the
>  limitations to the end user.  Having TC rules mysteriously fail to be
>  offloaded with no indication of why is not a great UX :(

Yes, but everyone has the same problem.

> I couldn't see a way to handle this without vendor-specific ugliness,
>  but if you have a proposal I don't mind putting in some work to
>  implement it.

I won't help with the indirect stuff, I fixed it once a while
back already and it keeps getting broken. It must be a case of 
the extack not being plumbed thru, or people being conservative
because the errors are not fatal, right? Solvable.

The printf'ing? I recon something simple like adding a destructor 
for the message to the exack struct so you can allocate the message, 
or adding a small buffer in place (the messages aren't very long,
usually) come to mind.