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: <bb50c952-6075-d838-0bc3-4848c12ad920@linux.ibm.com>
Date:   Mon, 30 Jan 2023 22:10:46 +0100
From:   Wenjia Zhang <wenjia@...ux.ibm.com>
To:     "D. Wythe" <alibuda@...ux.alibaba.com>, jaka@...ux.ibm.com,
        kgraul@...ux.ibm.com
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: [PATCH net-next v6 1/7] net/smc: remove locks
 smc_client_lgr_pending and smc_server_lgr_pending



On 30.01.23 11:51, D. Wythe wrote:
> 
> 
> On 1/30/23 4:37 PM, Wenjia Zhang wrote:
>>
>>
>> On 29.01.23 16:11, D. Wythe wrote:
>>>
>>>
>>> On 11/26/22 5:03 PM, D.Wythe wrote:
>>>> From: "D. Wythe" <alibuda@...ux.alibaba.com>
>>>>
>>>> This patch attempts to remove locks named smc_client_lgr_pending and
>>>> smc_server_lgr_pending, which aim to serialize the creation of link
>>>> group. However, once link group existed already, those locks are
>>>> meaningless, worse still, they make incoming connections have to be
>>>> queued one after the other.
>>>>
>>>> Now, the creation of link group is no longer generated by competition,
>>>> but allocated through following strategy.
>>>>
>>>
>>>
>>> Hi, all
>>>
>>> I have noticed that there may be some difficulties in the advancement 
>>> of this series of patches.
>>> I guess the main problem is to try remove the global lock in this 
>>> patch, the risks of removing locks
>>> do harm to SMC-D, at the same time, this patch of removing locks is 
>>> also a little too complex.
>>>
>>> So, I am considering that we can temporarily delay the advancement of 
>>> this patch. We can works on
>>> other patches first. Other patches are either simple enough or have 
>>> no obvious impact on SMC-D.
>>>
>>> What do you think?
>>>
>>> Best wishes.
>>> D. Wythe
>>>
>>>
>> Hi D. Wythe,
>>
>> that sounds good. Thank you for your consideration about SMC-D!
> 
> Hi Wenjia,
> 
> Thanks for your reply.
> 
>> Removing locks is indeed a big issue, those patches make us difficult 
>> to accept without thoroughly testing in every corner.
>>
>> Best
>> Wenjia
> 
> What do you mean by those patches? My plan is to delete the first patch 
> in this series,
> that is, 'remove locks smc_client_lgr_pending and 
> smc_server_lgr_pending', while other patches
> should be retained.
> 
> They has almost nothing impact on SMC-D or simple enough to be tested. 
> If you agree with this,
> I can then issue the next version as soon as possible to remove the 
> first patch, and I think
> we can quickly promote those patches.
> 
> Thanks.
> Wenjia
> 
Except for the removing locks of smc_client_lgr_pending and 
smc_server_lgr_pending, I'm still not that sure if running 
SMC_LLC_FLOW_RKEY concurrently could make the communication between our 
Linux and z/OS broken, that we can not test currently, though I really 
like this idea.
Sure, you can send the next version, I'll find a way to verify it.



> 
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ