[PATCH 3/6] nvme-auth: use xarray instead of linked list

Hannes Reinecke hare at suse.de
Wed Nov 2 01:52:24 PDT 2022


On 11/2/22 09:03, Christoph Hellwig wrote:
>> @@ -907,33 +915,28 @@ EXPORT_SYMBOL_GPL(nvme_auth_negotiate);
>>   int nvme_auth_wait(struct nvme_ctrl *ctrl, int qid)
>>   {
>>   	struct nvme_dhchap_queue_context *chap;
>> -	int ret;
>>   
>> +	chap = xa_load(&ctrl->dhchap_auth_xa, qid);
>> +	if (!chap) {
>> +		dev_warn(ctrl->device,
>> +			 "qid %d: authentication not initialized!",
>> +			 qid);
>> +		return -ENOENT;
>>   	}
>> +	flush_work(&chap->auth_work);
> 
> What protects chap from going away after the load, but before use?
> 

The control flow.
Entries are only deallocated in nvme_auth_free(), which is called from 
nvme_free_ctrl().
By that time all processing has stopped, all workqueue entries are 
flushed, and no further commands are accepted.
Entries are allocated from two call sites; one via ops->create_ctrl(), 
and the other one via the workqueue function nvme_dhchap_auth_work().
'create_ctrl' is synchronous, so the controller will only be deallocated 
on the final put() of the create_ctrl() control flow. So we should be 
good there.
The workqueue function is flushed during nvme_free_ctrl(), so we're good 
there, too.

Hence I felt additional protection is not required.
Do correct me if I'm wrong.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer




More information about the Linux-nvme mailing list