netdev - Re: [EXT] Re: bnx2x: ppc64le: Unable to set message level greater than 0x7fff

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]

Date:   Wed, 16 Mar 2022 12:18:25 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     Manish Chopra <manishc@...vell.com>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Ariel Elior <aelior@...vell.com>,
        Sudarsana Reddy Kalluru <skalluru@...vell.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "it+netdev@...gen.mpg.de" <it+netdev@...gen.mpg.de>
Subject: Re: [EXT] Re: bnx2x: ppc64le: Unable to set message level greater
 than 0x7fff

On Wed, 16 Mar 2022 19:52:32 +0100 Michal Kubecek wrote:
> > Yup, IIUC it works for Paul on a 5.17 system, that system likely has
> > old ethtool user space tool which uses ioctls instead of netlink.
> > 
> > What makes the netlink path somewhat non-trivial is that there is 
> > an expectation that the communication can be based on names (strings)
> > as well as bit positions. I think we'd need a complete parallel
> > attribute to carry vendor specific bits :S  
> 
> Yes, that would be a way to go. However, in such case I would prefer
> separating these driver/device specific message flags completely rather
> then letting drivers grab currently unused flags (as is the case here,
> IIUC) as those are likely to collide with future global ones.

I was thinking let the driver specify which flags it is squatting on in
a mask in ethtool_ops, and then make sure the generic vs non-generic
flags are routed appropriately in the user space <> core communication.
We can also split the private vs generic on the ethtool_op level.

User space would have to jump thru extra hoops to figure the separation
out (maybe we can expose the "private mask" in get?)

I agree that the more we can separate the private and generic flags,
the better, that's just what I could come up with.