linux-kernel - Re: [RFC PATCH net v2 2/2] net/smc: Resolve the race between SMC-R link access and clear

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: <7311029c-2c56-d9c7-9ed5-87bc6a36511f@linux.ibm.com>
Date:   Wed, 29 Dec 2021 13:51:27 +0100
From:   Karsten Graul <kgraul@...ux.ibm.com>
To:     Wen Gu <guwen@...ux.alibaba.com>, davem@...emloft.net,
        kuba@...nel.org
Cc:     linux-s390@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, dust.li@...ux.alibaba.com,
        tonylu@...ux.alibaba.com
Subject: Re: [RFC PATCH net v2 2/2] net/smc: Resolve the race between SMC-R
 link access and clear

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!