public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Wen Gu <guwen@linux.alibaba.com>
To: Wenjia Zhang <wenjia@linux.ibm.com>,
	shaozhengchao <shaozhengchao@huawei.com>,
	jaka@linux.ibm.com, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com
Cc: alibuda@linux.alibaba.com, tonylu@linux.alibaba.com,
	linux-s390@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net/smc: delete buf_desc from buffer list under lock protection
Date: Mon, 5 Aug 2024 17:31:32 +0800	[thread overview]
Message-ID: <b55a530a-4b22-453e-84dc-0bd5583aced6@linux.alibaba.com> (raw)
In-Reply-To: <800b1186-2d87-4b20-9d38-b4fecde161f0@linux.ibm.com>



On 2024/8/5 16:23, Wenjia Zhang wrote:
> 
> 
> 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.
> 

OK, let's handle it when it causes actual problems. Thanks!

> Thanks,
> Wenjia

      reply	other threads:[~2024-08-05  9:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31  9:31 [PATCH net] net/smc: delete buf_desc from buffer list under lock protection Wen Gu
2024-07-31 10:32 ` shaozhengchao
2024-08-02  1:55   ` Wen Gu
2024-08-05  8:23     ` Wenjia Zhang
2024-08-05  9:31       ` Wen Gu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b55a530a-4b22-453e-84dc-0bd5583aced6@linux.alibaba.com \
    --to=guwen@linux.alibaba.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jaka@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shaozhengchao@huawei.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=wenjia@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox