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]

Message-ID: <e563f5a5-2d1a-fbc9-be2d-986b050c6548@amd.com>
Date:   Mon, 13 Mar 2023 12:07:16 +0530
From:   Gautam Dawar <gdawar@....com>
To:     Jason Wang <jasowang@...hat.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

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.
>
>> 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;
         }

>
> 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
>>