netdev - Re: [PATCH net-next 2/2] ionic: support sr-iov operations

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]

Message-ID: <66e99536-43b5-ad8c-4af0-46a73a7e1d7a@mellanox.com>
Date:   Wed, 11 Dec 2019 04:40:31 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Shannon Nelson <snelson@...sando.io>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH net-next 2/2] ionic: support sr-iov operations

On 12/10/2019 9:20 PM, Shannon Nelson wrote:
> On 12/10/19 5:39 PM, Parav Pandit wrote:
>> On 12/10/2019 4:54 PM, Shannon Nelson wrote:
>>> Add the netdev ops for managing VFs.  Since most of the
>>> management work happens in the NIC firmware, the driver becomes
>>> mostly a pass-through for the network stack commands that want
>>> to control and configure the VFs.
>>>
>>> We also tweak ionic_station_set() a little to allow for
>>> the VFs that start off with a zero'd mac address.
>>>
>>> Signed-off-by: Shannon Nelson <snelson@...sando.io>
>>> ---
> [...]
>>>   +/* VF commands */
>>> +int ionic_set_vf_config(struct ionic *ionic, int vf, u8 attr, u8 *data)
>>> +{
>> I forgot to mention in my previous review comment that set_vf_config()
>> and other VF config friend callback functions can race with
>> ionic_sriov_configure().
>>
>> Former is called from netlink context, later is called from sysfs.
>> Its not too hard to crash the system both racing with each other.
>>
>> Hence protect them using rwsem, where set_vf_() and sriov_configure()
>> does down/up_write() and get_vf_config() and get_vf_stat() does
>> down_up/read().
>>
>>
> 
> Ah, good catch.  That seems to be relatively a new thing and with a
> quick look around it seems not many drivers deal with that yet. Thanks
> for pointing it out.
>
Yes. I am aware of it for a while. I am fixing mlx5 driver currently.

> sln
>