Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC net-next 0/8] Introducing subdev bus and devlink extension
To:     Parav Pandit <parav@nvidia.com>, Jakub Kicinski <kuba@kernel.org>
CC:     moyufeng <moyufeng@huawei.com>,
        Jakub Kicinski <jakub.kicinski@netronome.com>,
        Jiri Pirko <jiri@resnulli.us>,
        Or Gerlitz <gerlitz.or@gmail.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "michal.lkml@markovi.net" <michal.lkml@markovi.net>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        Jiri Pirko <jiri@nvidia.com>,
        Salil Mehta <salil.mehta@huawei.com>,
        "lipeng (Y)" <lipeng321@huawei.com>,
        Guangbin Huang <huangguangbin2@huawei.com>,
        "shenjian15@huawei.com" <shenjian15@huawei.com>,
        "chenhao (DY)" <chenhao288@hisilicon.com>,
        Jiaran Zhang <zhangjiaran@huawei.com>,
        "linuxarm@openeuler.org" <linuxarm@openeuler.org>
References: <1551418672-12822-1-git-send-email-parav@mellanox.com>
 <857e7a19-1559-b929-fd15-05e8f38e9d45@huawei.com>
 <20210603105311.27bb0c4d@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
 <c9afecb5-3c0e-6421-ea58-b041d8173636@huawei.com>
 <20210604114109.3a7ada85@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
 <4e7a41ed-3f4d-d55d-8302-df3bc42dedd4@huawei.com>
 <20210607124643.1bb1c6a1@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
 <530ff54c-3cee-0eb6-30b0-b607826f68cf@huawei.com>
 <20210608102945.3edff79a@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
 <2acd8373-b3dc-4920-1cbe-2b5ae29acb5b@huawei.com>
 <DM8PR12MB54802CA9A47F1585DC3347A5DC369@DM8PR12MB5480.namprd12.prod.outlook.com>
 <d54ae715-8634-c983-1602-8cd8dea2a5e2@huawei.com>
 <DM8PR12MB5480F577E5F02105B8C1FE9BDC369@DM8PR12MB5480.namprd12.prod.outlook.com>
 <acf08577-34c6-bc9e-a788-568b67fa8d2e@huawei.com>
 <DM8PR12MB5480CA5904F1242202F9D51ADC369@DM8PR12MB5480.namprd12.prod.outlook.com>
From:   Yunsheng Lin <linyunsheng@huawei.com>
Message-ID: <387c80e7-e50f-8f2f-0fea-d699902ef84e@huawei.com>
Date:   Thu, 10 Jun 2021 15:04:24 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <DM8PR12MB5480CA5904F1242202F9D51ADC369@DM8PR12MB5480.namprd12.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2021/6/9 21:45, Parav Pandit wrote:
 >> From: Yunsheng Lin <linyunsheng@huawei.com>
>> Sent: Wednesday, June 9, 2021 6:00 PM
>>
>> On 2021/6/9 19:59, Parav Pandit wrote:
>>>> From: Yunsheng Lin <linyunsheng@huawei.com>
>>>> Sent: Wednesday, June 9, 2021 4:35 PM
>>>>
>>>> On 2021/6/9 17:38, Parav Pandit wrote:
>>>>>
>>>>>> From: Yunsheng Lin <linyunsheng@huawei.com>
>>>>>> Sent: Wednesday, June 9, 2021 2:46 PM
>>>>>>
>>>>> [..]
>>>>>
>>>>>>>> Is there any reason why VF use its own devlink instance?
>>>>>>>
>>>>>>> Primary use case for VFs is virtual environments where guest isn't
>>>>>>> trusted, so tying the VF to the main devlink instance, over which
>>>>>>> guest should have no control is counter productive.
>>>>>>
>>>>>> The security is mainly about VF using in container case, right?
>>>>>> Because VF using in VM, it is different host, it means a different
>>>>>> devlink instance for VF, so there is no security issue for VF using
>>>>>> in VM
>>>> case?
>>>>>> But it might not be the case for VF using in container?
>>>>> Devlink instance has net namespace attached to it controlled using
>>>>> devlink
>>>> reload command.
>>>>> So a VF devlink instance can be assigned to a container/process
>>>>> running in a
>>>> specific net namespace.
>>>>>
>>>>> $ ip netns add n1
>>>>> $ devlink dev reload pci/0000:06:00.4 netns n1
>>>>>                                      ^^^^^^^^^^^^^
>>>>>                                      PCI VF/PF/SF.
>>>>
>>>> Could we create another devlink instance when the net namespace of
>>>> devlink port instance is changed?
>>> Net namespace of (a) netdevice (b) rdma device (c) devlink instance can be
>> changed.
>>> Net namespace of devlink port cannot be changed.
>>
>> Yes, net namespace is changed based on the devlink instance, not devlink
>> port instance, *right now*.
>>
>>>
>>>> It may seems we need to change the net namespace based on devlink
>>>> port instance instead of devlink instance.
>>>> This way container case seems be similiar to the VM case?
>>> I mostly do not understand the topology you have in mind or if you
>> explained previously I missed the thread.
>>> In your case what is the flavour of a devlink port?
>>
>> flavour of the devlink port instance is FLAVOUR_PHYSICAL or
>> FLAVOUR_VIRTUAL.
>>
>> The reason I suggest to change the net namespace on devlink port instance
>> instead of devlink instance is：
>> I proposed that all the PF and VF in the same ASIC are registered to the same
>> devlink instance as flavour FLAVOUR_PHYSICAL or FLAVOUR_VIRTUAL when
>> there are in the same host and in the same net namespace.
>>
>> If a VF's devlink port instance is unregistered from old devlink instance in the
>> old net namespace and registered to new devlink instance in the new net
>> namespace(create a new devlink instance if
>> needed) when devlink port instance's net namespace is changed, then the
>> security mentioned by jakub is not a issue any more?
> 
> It seems that devlink instance of VF is not needed in your case, and if so what is the motivation to even have VIRTUAL port attach to the PF?

The devlink instance is mainly used to hold the devlink port instance
of VF if there is only one VF in vm, we might still need to have
param/health specific to the VF to registered to the devlink port
instance of that VF.

> If only netdevice of the VF is of interest, it can be assigned to net namespace directly.

I think that is another option, if there is nothing in the devlink port
instance specific to VF that need exposing to the user in another net
namespace.

> 
> It doesn’t make sense to me to create new devlink instance in new net namespace, that also needs to be deleted when net ns is deleted.
> And pre_exit() routine will mostly deadlock holding global devlink_mutex.

Would you be more specific why there is deadlock?
It seems more of implementation detail, which we can discuss later
when we are agreed it is the right way to go down deeper?

>