netdev - Re: [PATCH net-next v2 13/14] sfc: update vdpa device MAC address

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]

Date:   Wed, 15 Mar 2023 12:50:55 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Gautam Dawar <gdawar@....com>, Gautam Dawar <gautam.dawar@....com>
Cc:     linux-net-drivers@....com, Edward Cree <ecree.xilinx@...il.com>,
        Martin Habets <habetsm.xilinx@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Richard Cochran <richardcochran@...il.com>,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        eperezma@...hat.com, harpreet.anand@....com, tanuj.kamde@....com,
        koushik.dutta@....com
Subject: Re: [PATCH net-next v2 13/14] sfc: update vdpa device MAC address


在 2023/3/13 14:37, Gautam Dawar 写道:
> On 3/10/23 10:35, Jason Wang wrote:
>> Caution: This message originated from an External Source. Use proper 
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> On Tue, Mar 7, 2023 at 7:38 PM Gautam Dawar <gautam.dawar@....com> 
>> wrote:
>>> As the VF MAC address can now be updated using `devlink port 
>>> function set`
>> What happens if we run this while the vpda is being used by a VM?
> IIUC, updating the MAC address using devlink interface requires 
> unbinding the device from driver and hence updating the MAC while vdpa 
> device is in-use won't be possible. It can only be done via control vq 
> VIRTIO_NET_CTRL_MAC_ADDR_SET command, when available.


Good to know that.


>>
>>> interface, fetch the vdpa device MAC address from the underlying VF 
>>> during
>>> vdpa device creation.
>>>
>>> Signed-off-by: Gautam Dawar <gautam.dawar@....com>
>>> ---
>>>   drivers/net/ethernet/sfc/ef100_vdpa.c | 12 ++++++++++++
>>>   1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/sfc/ef100_vdpa.c 
>>> b/drivers/net/ethernet/sfc/ef100_vdpa.c
>>> index 30ca4ab00175..32182a01f6a5 100644
>>> --- a/drivers/net/ethernet/sfc/ef100_vdpa.c
>>> +++ b/drivers/net/ethernet/sfc/ef100_vdpa.c
>>> @@ -272,6 +272,18 @@ static int get_net_config(struct ef100_vdpa_nic 
>>> *vdpa_nic)
>>>          vdpa_nic->net_config.max_virtqueue_pairs =
>>>                  cpu_to_efx_vdpa16(vdpa_nic, 
>>> vdpa_nic->max_queue_pairs);
>>>
>>> +       rc = ef100_get_mac_address(efx, vdpa_nic->mac_address,
>>> +                                  efx->client_id, true);
>>> +       if (rc) {
>>> +               dev_err(&vdpa_nic->vdpa_dev.dev,
>>> +                       "%s: Get MAC for vf:%u failed:%d\n", __func__,
>>> +                       vdpa_nic->vf_index, rc);
>>> +               return rc;
>>> +       }
>> Can this override what is provisioned by the userspace?
>
> No, this was carefully avoided by overwriting the userspace 
> provisioned MAC in ef100_vdpa_create():
>
>         rc = get_net_config(vdpa_nic);
>         if (rc)
>                 goto err_put_device;
>
>         if (mac) {
>                 ether_addr_copy(vdpa_nic->mac_address, mac);
>                 vdpa_nic->mac_configured = true;
>         }


Ah, I see.

Thanks


>
>>
>> Thanks
>>
>>
>>> +
>>> +       if (is_valid_ether_addr(vdpa_nic->mac_address))
>>> +               vdpa_nic->mac_configured = true;
>>> +
>>>          rc = efx_vdpa_get_mtu(efx, &mtu);
>>>          if (rc) {
>>>                  dev_err(&vdpa_nic->vdpa_dev.dev,
>>> -- 
>>> 2.30.1
>>>
>