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] [day] [month] [year] [list]

Date:   Fri, 6 Mar 2020 14:57:29 -0800
From:   Shannon Nelson <snelson@...sando.io>
To:     Jakub Kicinski <kuba@...nel.org>
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 3/6/20 1:28 PM, Jakub Kicinski wrote:
> 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?

Being as this is still a new idea for us and we aren't up to speed yet 
on what all devlink offers, I don't have a good answer at the moment.  
For now, nothing more than already exposed, which is simple device info.

sln