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: <800b1186-2d87-4b20-9d38-b4fecde161f0@linux.ibm.com>
Date: Mon, 5 Aug 2024 10:23:15 +0200
From: Wenjia Zhang <wenjia@...ux.ibm.com>
To: Wen Gu <guwen@...ux.alibaba.com>,
        shaozhengchao
 <shaozhengchao@...wei.com>, jaka@...ux.ibm.com,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com
Cc: alibuda@...ux.alibaba.com, tonylu@...ux.alibaba.com,
        linux-s390@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net/smc: delete buf_desc from buffer list under lock
 protection



On 02.08.24 03:55, Wen Gu wrote:
> 
> 
> On 2024/7/31 18:32, shaozhengchao wrote:
>> Hi Wen Gu:
>>    "The operations to link group buffer list should be protected by
>> sndbufs_lock or rmbs_lock" It seems that the logic is smooth. But will
>> this really happen? Because no process is in use with the link group,
>> does this mean that there is no concurrent scenario?
>>
> 
> Hi Zhengchao,
> 
> Yes, I am also very conflicted about whether to add lock protection.
>  From the code, it appears that when __smc_lgr_free_bufs is called, the
> link group has already been removed from the lgr_list, so theoretically
> there should be no contention (e.g. add to buf_list). However, in order
> to maintain consistency with other lgr buf_list operations and to guard
> against unforeseen or future changes, I have added lock protection here
> as well.
> 
> Thanks!
> 

I'm indeed in two minds about if I give you my reviewed-by especially on 
the reason of unforeseen bugs. However, previously the most bugs on 
locking we met in our code are almost because of deadlocks caused by too 
much different locks introduced. Thus, I don't think this patch is 
necessary at lease for now.

Thanks,
Wenjia

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ