All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	Keith Busch <kbusch@kernel.org>,
	linux-nvme@lists.infradead.org
Subject: Re: [PATCH 3/6] nvme-auth: use xarray instead of linked list
Date: Wed, 2 Nov 2022 09:54:33 +0100	[thread overview]
Message-ID: <20221102085433.GA14462@lst.de> (raw)
In-Reply-To: <c1e10a5e-eab1-c49c-4377-54a94457df5e@suse.de>

On Wed, Nov 02, 2022 at 09:52:24AM +0100, Hannes Reinecke wrote:
> 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.

I'm not up to speed on the auth code.  But something like this
needs to be clearly documented in the commit log, and preferably
in the code as well.


  reply	other threads:[~2022-11-02  8:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02  7:52 [PATCH 0/6] nvme-auth: use xarray and minor fixes Hannes Reinecke
2022-11-02  7:52 ` [PATCH 1/6] nvme-auth: allocate authentication buffer only during transaction Hannes Reinecke
2022-11-03 20:01   ` Sagi Grimberg
2022-11-04  6:49     ` Hannes Reinecke
2022-11-04  6:55       ` Christoph Hellwig
2022-11-02  7:52 ` [PATCH 2/6] nvme-auth: do not queue authentication if the queue is not live Hannes Reinecke
2022-11-03 21:19   ` Sagi Grimberg
2022-11-04  6:54     ` Hannes Reinecke
2022-11-02  7:52 ` [PATCH 3/6] nvme-auth: use xarray instead of linked list Hannes Reinecke
2022-11-02  8:03   ` Christoph Hellwig
2022-11-02  8:52     ` Hannes Reinecke
2022-11-02  8:54       ` Christoph Hellwig [this message]
2022-11-03 21:20   ` Sagi Grimberg
2022-11-04  6:57     ` Hannes Reinecke
2022-11-02  7:52 ` [PATCH 4/6] nvme-auth: return real error instead of NVME_SC_AUTH_REQUIRED Hannes Reinecke
2022-11-02  7:52 ` [PATCH 5/6] nvme-auth: set DNR bit on non-retryable errors Hannes Reinecke
2022-11-02  8:02   ` Christoph Hellwig
2022-11-02  8:40     ` Hannes Reinecke
2022-11-02  7:52 ` [PATCH 6/6] nvme-auth: use a define for chap buffer size Hannes Reinecke
2022-11-03 21:22   ` Sagi Grimberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221102085433.GA14462@lst.de \
    --to=hch@lst.de \
    --cc=hare@suse.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.