netdev - Re: [PATCH v3 net-next 7/8] ionic: add support for device id 0x1004

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: <20200306132825.2568127a@kicinski-fedora-PC1C0HJN>
Date:   Fri, 6 Mar 2020 13:28:25 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Shannon Nelson <snelson@...sando.io>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH v3 net-next 7/8] ionic: add support for device id 0x1004

On Fri, 6 Mar 2020 12:32:51 -0800 Shannon Nelson wrote:
> >> However, this device id does exist on some of the DSC configurations,
> >> and I'd prefer to explicitly acknowledge its existence in the driver and
> >> perhaps keep better control over it, whether or not it gets used by our
> >> 3rd party tool, rather than leave it as some obscure port for someone to
> >> "discover".  
> > I understand, but disagree. Your driver can certainly bind to that
> > management device but it has to be for the internal use of the kernel.
> > You shouldn't just expose that FW interface right out to user space as
> > a netdev.  
> 
> So for now the driver should simply capture and configure the PCI 
> device, but stop at that point and not setup a netdev.  This would leave 
> the device available for devlink commands.
> 
> If that sounds reasonable to you, I'll add it and respin the patchset.

I presume the driver currently creates a devlink instance per PCI
function? (Given we have no real infrastructure in place to combine
them.) It still feels a little strange to have a devlink instance that
doesn't represent any entity user would care about, but a communication
channel. It'd be better if other functions made use of the
communication channel behind the scene. That said AFAIU driver with just
a devlink instance won't allow passing arbitrary commands, so that would
indeed address my biggest concern.

What operations would that devlink instance expose?