Re: [SPDK] Report a potential race condition in nvmf target

[Lorne Li <lorneli at 163.com>]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

Hi Ziye, Sasha,


Thanks for your quick response.


I have submitted a patch trying to fix this.   https://review.gerrithub.io/c/spdk/spdk/+/459144


Please correct me if I didn't fix it in the right way.


|
Lorne Li
lorneli(a)163.com
|
签名由网易邮箱大师定制
On 6/24/2019 16:22，Yang, Ziye<ziye.yang(a)intel.com> wrote：
Hi Lorne,

I think that your concern is right. When a subsystem is adding/deleting a namespace. The event should be propagated to any active ctrlr built on this subsystem, and the operation on the ctrlr's operation should be executed on the thread who creates the ctrlr.

Can you submit a patch to address this if you have time?

Thanks.




Best Regards
Ziye Yang


-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Lorne Li
Sent: Monday, June 24, 2019 3:15 PM
To: spdk-dev <spdk(a)lists.01.org>
Subject: [SPDK] Report a potential race condition in nvmf target



Hi all,


I think there may exist a race condition in nvmf target.


When adding or removing a namespace,  nvmf target using `spdk_nvmf_ctrlr_ns_changed` to notify its ctrlr that ns has been changed from subsystem's thread('app thread'). But I think func  `spdk_nvmf_ctrlr_ns_changed` should be called in ctrlr's thread, since it touches ctrlr's variables and even transfers out ctrlr's aer_req.


Last week, I launched a issue https://github.com/spdk/spdk/issues/837 in github to describe this race condition in detail and a panic likely caused by this.


It would be great if someone could take a look at it. Thanks in advance.


|
Lorne Li
lorneli(a)163.com
|
签名由网易邮箱大师定制
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk