Message-ID: <7311029c-2c56-d9c7-9ed5-87bc6a36511f@linux.ibm.com>
Date:   Wed, 29 Dec 2021 13:51:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.1
Subject: Re: [RFC PATCH net v2 2/2] net/smc: Resolve the race between SMC-R
 link access and clear
Content-Language: en-US
To:     Wen Gu <guwen@linux.alibaba.com>, davem@davemloft.net,
        kuba@kernel.org
Cc:     linux-s390@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, dust.li@linux.alibaba.com,
        tonylu@linux.alibaba.com
References: <1640704432-76825-1-git-send-email-guwen@linux.alibaba.com>
 <1640704432-76825-3-git-send-email-guwen@linux.alibaba.com>
From:   Karsten Graul <kgraul@linux.ibm.com>
Organization: IBM Deutschland Research & Development GmbH
In-Reply-To: <1640704432-76825-3-git-send-email-guwen@linux.alibaba.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 28/12/2021 16:13, Wen Gu wrote:
> We encountered some crashes caused by the race between SMC-R
> link access and link clear triggered by link group termination
> in abnormal case, like port error.

Without to dig deeper into this, there is already a refcount for links, see smc_wr_tx_link_hold().
In smc_wr_free_link() there are waits for the refcounts to become zero.

Why do you need to introduce another refcounting instead of using the existing?
And if you have a good reason, do we still need the existing refcounting with your new
implementation?

Maybe its enough to use the existing refcounting in the other functions like smc_llc_flow_initiate()?

Btw: it is interesting what kind of crashes you see, we never met them in our setup.
Its great to see you evaluating SMC in a cloud environment!