[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