All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Bogdanov <d.bogdanov@yadro.com>
To: Guixin Liu <kanie@linux.alibaba.com>
Cc: Sagi Grimberg <sagi@grimberg.me>, <hch@lst.de>, <kch@nvidia.com>,
	<shinichiro.kawasaki@wdc.com>, <linux-nvme@lists.infradead.org>
Subject: Re: [PATCH v17 2/2] nvmet: support reservation feature
Date: Wed, 23 Oct 2024 16:30:33 +0300	[thread overview]
Message-ID: <20241023133033.GN22571@yadro.com> (raw)
In-Reply-To: <ac5147d1-59ae-4bdc-abba-f57d85972b4d@linux.alibaba.com>

On Wed, Oct 23, 2024 at 03:06:10PM +0800, Guixin Liu wrote:
> 在 2024/10/22 21:18, Sagi Grimberg 写道:
> > > +static void nvmet_execute_pr_acquire(struct nvmet_req *req)
> > > +{
> > > +    u32 cdw10 = le32_to_cpu(req->cmd->common.cdw10);
> > > +    bool ignore_key = nvmet_pr_parse_ignore_key(cdw10);
> > > +    /* Reservation type, bit 15:08 */
> > > +    u8 rtype = (u8)((cdw10 >> 8) & 0xff);
> > > +    /* Reservation acquire action, bit 02:00 */
> > > +    u8 acquire_act = cdw10 & 0x07;
> > > +    struct nvmet_ctrl *ctrl = req->sq->ctrl;
> > > +    struct nvmet_pr_acquire_data *d = NULL;
> > > +    struct nvmet_pr *pr = &req->ns->pr;
> > > +    struct nvmet_pr_registrant *reg;
> > > +    u16 status = NVME_SC_SUCCESS;
> > > +
> > > +    if (ignore_key ||
> > > +        rtype < NVME_PR_WRITE_EXCLUSIVE ||
> > > +        rtype > NVME_PR_EXCLUSIVE_ACCESS_ALL_REGS) {
> > > +        status = NVME_SC_INVALID_FIELD | NVME_STATUS_DNR;
> > > +        goto out;
> > > +    }
> > > +
> > > +    d = kmalloc(sizeof(*d), GFP_KERNEL);
> > > +    if (!d) {
> > > +        status = NVME_SC_INTERNAL;
> > > +        goto out;
> > > +    }
> > > +
> > > +    status = nvmet_copy_from_sgl(req, 0, d, sizeof(*d));
> > > +    if (status)
> > > +        goto free_data;
> > > +
> > > +    status = NVME_SC_RESERVATION_CONFLICT | NVME_STATUS_DNR;
> > > +    mutex_lock(&pr->pr_lock);
> > > +    list_for_each_entry_rcu(reg, &pr->registrant_list, entry,
> > > +                lockdep_is_held(&pr->pr_lock)) {
> > > +        if (uuid_equal(&reg->hostid, &ctrl->hostid) &&
> > > +            reg->rkey == le64_to_cpu(d->crkey)) {
> > > +            status = __nvmet_execute_pr_acquire(req, reg,
> > > +                    acquire_act, rtype, d);
> > > +            break;
> > > +        }
> > > +    }
> > > +
> > > +    if (!status && acquire_act ==
> > > NVME_PR_ACQUIRE_ACT_PREEMPT_AND_ABORT) {
> > > +        kfree(d);
> > > +        INIT_WORK(&req->r.abort_work, nvmet_pr_do_abort);
> > > +        queue_work(nvmet_wq, &req->r.abort_work);
> > > +        return;
> > > +    }
> > 
> > Is there a reason why you queue this here and not inside
> > __nvmet_execute_pr_acquire
> > like before?
> > 
> Because I should add a "if" branch here to prevent unlock the pr_lock
> and complete
> 
> the request. Instead of twice "if", I merge them to one, just let
> __nvmet_execute_pr_acquire()
> 
> return status.
> 
> > > +
> > > +    mutex_unlock(&pr->pr_lock);
> > 
> > Hmm... you keep this mutex taken and release it from the work element
> > async... Not a
> > great practice...
> > 
> > Any easy way you see to avoid this?
> 
> Sure, this is not a greate practice, I will think deeply and find
> another way.
>

Guixin, please, take a look whether keeping that mutex locked during
aborting is actually needed or not. Probably there is no such need -
pr_lock protects ns.pr.registrants_list which is not touched in abort
procedure.

BR,
 Dmitry


  reply	other threads:[~2024-10-23 13:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-21 11:03 [PATCH v17 0/2] Implement the NVMe reservation feature Guixin Liu
2024-10-21 11:03 ` [PATCH v17 1/2] nvme: add reservation command's defines Guixin Liu
2024-10-21 11:03 ` [PATCH v17 2/2] nvmet: support reservation feature Guixin Liu
2024-10-21 22:33   ` Keith Busch
2024-10-22  1:43     ` Guixin Liu
2024-10-22  2:07       ` Keith Busch
2024-10-22  6:06         ` Christoph Hellwig
2024-10-22 14:13           ` Jens Axboe
2024-10-22 14:18             ` Jens Axboe
2024-10-22 14:19               ` Christoph Hellwig
2024-10-22 14:34               ` Keith Busch
2024-10-22 13:18   ` Sagi Grimberg
2024-10-22 14:20     ` Christoph Hellwig
2024-10-23  7:35       ` Guixin Liu
2024-10-23 12:24         ` Christoph Hellwig
2024-10-24  1:32           ` Guixin Liu
2024-10-23  7:06     ` Guixin Liu
2024-10-23 13:30       ` Dmitry Bogdanov [this message]
2024-10-24  2:04         ` Guixin Liu

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=20241023133033.GN22571@yadro.com \
    --to=d.bogdanov@yadro.com \
    --cc=hch@lst.de \
    --cc=kanie@linux.alibaba.com \
    --cc=kch@nvidia.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=shinichiro.kawasaki@wdc.com \
    /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.