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: <3dc68650-904c-4a1d-adc4-172e771f640c@linux.alibaba.com>
Date: Wed, 15 Jan 2025 19:53:15 +0800
From: Guangguan Wang <guangguan.wang@...ux.alibaba.com>
To: Halil Pasic <pasic@...ux.ibm.com>
Cc: Paolo Abeni <pabeni@...hat.com>, wenjia@...ux.ibm.com,
 jaka@...ux.ibm.com, alibuda@...ux.alibaba.com, tonylu@...ux.alibaba.com,
 guwen@...ux.alibaba.com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, horms@...nel.org, linux-rdma@...r.kernel.org,
 linux-s390@...r.kernel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, Alexandra Winter <wintera@...ux.ibm.com>
Subject: Re: [PATCH net] net/smc: use the correct ndev to find pnetid by
 pnetid table



On 2025/1/14 20:07, Halil Pasic wrote:
> On Fri, 10 Jan 2025 13:43:44 +0800
> Guangguan Wang <guangguan.wang@...ux.alibaba.com> wrote:
> 
>>> I think I showed a valid and practical setup that would break with your
>>> patch as is. Do you agree with that statement?  
>> Did you mean
>> "
>> Now for something like a bond of two OSA
>> interfaces, I would expect the two legs of the bond to probably have a
>> "HW PNETID", but the netdev representing the bond itself won't have one
>> unless the Linux admin defines a software PNETID, which is work, and
>> can't have a HW PNETID because it is a software construct within Linux.
>> Breaking for example an active-backup bond setup where the legs have
>> HW PNETIDs and the admin did not bother to specify a PNETID for the bond
>> is not acceptable.
>> " ?
>> If the legs have HW pnetids, add pnetid to bond netdev will fail as
>> smc_pnet_add_eth will check whether the base_ndev already have HW pnetid.
>>
>> If the legs without HW pnetids, and admin add pnetids to legs through smc_pnet.
>> Yes, my patch will break the setup. What Paolo suggests(both checking ndev and
>> base_ndev, and replace || by && )can help compatible with the setup.
> 
> I'm glad we agree on that part. Things are much more acceptable if we
> are doing both base and ndev. 
It is also acceptable for me.

> Nevertheless I would like to understand
> your problem better, and talk about it to my team. I will also ask some
> questions in another email.
Questions are welcome.

> 
> That said having things work differently if there is a HW PNETID on
> the base, and different if there is none is IMHO wonky and again
> asymmetric.
> 
> Imagine the following you have your nice little setup with a PNETID on
> a non-leaf and a base_ndev that has no PNETID. Then your HW admin
> configures a PNETID to your base_ndev, a different one. Suddenly
> your ndev PNETID is ignored for reasons not obvious to you. Yes it is
> similar to having a software PNETID on the base_ndev and getting it
> overruled by a HW PNETID, but much less obvious IMHO. I am wondering if there are any scenarios that require setting different
pnetids for different net devices in one netdev hierarchy. If no, maybe
we should limit that only one pnetid can be set to one netdev hierarchy.

> I also think
> a software PNETID of the base should probably take precedence over over
> the software pnetid of ndev.
Agree!

Thanks,
Guangguan Wang
> 
> Regards,
> Halil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ