All of lore.kernel.org
 help / color / mirror / Atom feed
From: james_p_freyensee@linux.intel.com (J Freyensee)
Subject: [PATCH v2] nvmet: Don't queue fatal error work if csts.cfs is set
Date: Mon, 07 Nov 2016 10:41:17 -0800	[thread overview]
Message-ID: <1478544077.3350.26.camel@linux.intel.com> (raw)
In-Reply-To: <1478453200-16762-1-git-send-email-sagi@grimberg.me>

On Sun, 2016-11-06@19:26 +0200, Sagi Grimberg wrote:
> In the transport, in case of an interal queue error like
> error completion in rdma we trigger a fatal error. However,
> multiple queues in the same controller can serr error completions
> and we don't want to trigger fatal error work more than once.
> 
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> Signed-off-by: Sagi Grimberg <sagi at grimberg.me>
> ---
> Changes from v1:
> - reversed the if condition to avoid a goto statement
> 
> Changes from v0:
> - protect with ctrl lock instead of abusing atomic bitops on
> ????ctrl->csts
> 
> ?drivers/nvme/target/core.c | 10 +++++++---
> ?1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
> index 7c0fe31ee654..55ce769cecee 100644
> --- a/drivers/nvme/target/core.c
> +++ b/drivers/nvme/target/core.c
> @@ -840,9 +840,13 @@ static void nvmet_fatal_error_handler(struct
> work_struct *work)
> ?
> ?void nvmet_ctrl_fatal_error(struct nvmet_ctrl *ctrl)
> ?{
> -	ctrl->csts |= NVME_CSTS_CFS;
> -	INIT_WORK(&ctrl->fatal_err_work, nvmet_fatal_error_handler);
> -	schedule_work(&ctrl->fatal_err_work);
> +	mutex_lock(&ctrl->lock);
> +	if (!(ctrl->csts & NVME_CSTS_CFS)) {
> +		ctrl->csts |= NVME_CSTS_CFS;
> +		INIT_WORK(&ctrl->fatal_err_work,
> nvmet_fatal_error_handler);
> +		schedule_work(&ctrl->fatal_err_work);
> +	}
> +	mutex_unlock(&ctrl->lock);

Surrounding the mutex_lock()/unlock() around the if() is definitely
safer and a more conservative, but I would think it would be OK to
stick the mutex_lock/unlock() within the if() statement (mutex_lock()
as the first line after the if() check, mutex_unlock() as the last line
of the if()), as trying to acquire a lock before checking the condition
to see if CFS needs to be set is sub-optimal.

> ?}
> ?EXPORT_SYMBOL_GPL(nvmet_ctrl_fatal_error);
> ?

  reply	other threads:[~2016-11-07 18:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-06 17:26 [PATCH v2] nvmet: Don't queue fatal error work if csts.cfs is set Sagi Grimberg
2016-11-07 18:41 ` J Freyensee [this message]
2016-11-08 10:26   ` 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=1478544077.3350.26.camel@linux.intel.com \
    --to=james_p_freyensee@linux.intel.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.