Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2512664imm; Wed, 16 May 2018 14:13:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpZS4ZqGRn3KxwNZJRBgx9VQ5ksilosCnxP2NGdEMXUdcQWRIC5wSscD406i3OTjxZ+c8Zv X-Received: by 2002:a63:7c43:: with SMTP id l3-v6mr2052624pgn.0.1526505209368; Wed, 16 May 2018 14:13:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526505209; cv=none; d=google.com; s=arc-20160816; b=mdgqjU/CWEHZif/b+eCUe6uvvoC72ClSfmEiGZ/y94H8izP6SqIW6B20saF0BdP5Ql s+MB5unxsv7mtL7/Xk080ljdrEbHRma1BluZkrOTOAYB7GkU/mbK5qNHrTuM5I/kjuJ1 rKP2eA89pqGIKW0qbBH01wZWNsdVj67a4EHLZoy20DqxsDe4JBK37h/xBKA5Nvlujcei gKG380bGONtJk7oWpK/NMKjxoreI3713rYotJWwduKdMoIOXnJV0Lh71+p2BBqpdpqdu mjYx9jYumegN+6X13j3IukVMBZn1zk8lSWO+jPz1m4qbRN50gm96CSlDdUzSrU6A9/d8 mE6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=yuQIHQwYjG/TgYSpDKgsUR2J35C4e25nIN5C6CXGVYU=; b=uI/VQjWXfPWgfclQ22j+l5BeokzTe0Wf+oTnmMdqAfzTQj/EEFWazlJIE5aMNLX/8d LPiV4bI0b/+J/eYbzhfQVD8MeZ6N4txuRPSkAX4b76AitD67HfQotAZu7tfPR5duKiHO HqK+uaYCRncjXZvoLDlse/4jYP4IpIGglNCO/752PpXso2/ybnOewp79CxFa46FkS9A8 VWjA6uR73fQhX0PJhBsWLxlzpJRo0fls8VBJVmFeJYUCJF+uEdN62G7NTxWmFHgzOZ5s vb5hju/Cq55GG0PD9oIhdiuX5dxmTphnfHVyMys7jYmxSu5sO6GV/JSELHeUG629rMDO nyOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=larTUI6T; dkim=pass header.i=@codeaurora.org header.s=default header.b=UNOc3tDj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x3-v6si3225604plo.62.2018.05.16.14.13.14; Wed, 16 May 2018 14:13:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=larTUI6T; dkim=pass header.i=@codeaurora.org header.s=default header.b=UNOc3tDj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752214AbeEPVNH (ORCPT + 99 others); Wed, 16 May 2018 17:13:07 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:55022 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751307AbeEPVNF (ORCPT ); Wed, 16 May 2018 17:13:05 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 57E5360209; Wed, 16 May 2018 21:13:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526505185; bh=yc8ll5hsQFD9iusbnAt5706CevvmxHUKdWrbVlhc+6g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=larTUI6THpuEtG5IySZt4fx4DxQO8OP7viQgtzxr3kj1nLXfOVn9h41ddmqZ3MmDq dQNaVizqtaMF296pg2t4tLM6ZPfr8pZypUUGTpAb6Jxi0kg8biNvNdyAXN066BzlkX DQtjCbL7kdg0dpVuqpA0glVcHRipcoFkrR63PUnk= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 438576055C; Wed, 16 May 2018 21:13:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526505184; bh=yc8ll5hsQFD9iusbnAt5706CevvmxHUKdWrbVlhc+6g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UNOc3tDjVjA7WR63R8eC4VDxR8Y26G4keJ8QP3bcaybfxdavpQ/P94oJxzn7u17Nw pZaxvKM9X9dhzY4l6vw9wvy/sSCwcl8OWk7NLq4caSiKDvkiYGiZ/RTzgyPC1q39PH jV0ZJfH7VnnDttWvJUPSewimxtOf2ieXNv6gIis4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 May 2018 14:13:04 -0700 From: Subhash Jadavani To: Asutosh Das Cc: cang@codeaurora.org, vivek.gautam@codeaurora.org, rnayak@codeaurora.org, vinholikatti@gmail.com, jejb@linux.vnet.ibm.com, martin.petersen@oracle.com, linux-mmc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi-owner@vger.kernel.org Subject: Re: [PATCH v2 06/10] scsi: ufs: add reference counting for scsi block requests In-Reply-To: <3d524952ffe2c0a14c92f5e322aed5d2c24c2832.1525343531.git.asutoshd@codeaurora.org> References: <3d524952ffe2c0a14c92f5e322aed5d2c24c2832.1525343531.git.asutoshd@codeaurora.org> Message-ID: <8b854aae6759098ccc23f28b7c4da08d@codeaurora.org> X-Sender: subhashj@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-03 04:07, Asutosh Das wrote: > From: Subhash Jadavani > > Currently we call the scsi_block_requests()/scsi_unblock_requests() > whenever we want to block/unblock scsi requests but as there is no > reference counting, nesting of these calls could leave us in undesired > state sometime. Consider following call flow sequence: > 1. func1() calls scsi_block_requests() but calls func2() before > calling scsi_unblock_requests() > 2. func2() calls scsi_block_requests() > 3. func2() calls scsi_unblock_requests() > 4. func1() calls scsi_unblock_requests() > > As there is no reference counting, we will have scsi requests unblocked > after #3 instead of it to be unblocked only after #4. Though we may not > have failures seen with this, we might run into some failures in > future. > Better solution would be to fix this by adding reference counting. > > Signed-off-by: Subhash Jadavani > Signed-off-by: Can Guo > Signed-off-by: Asutosh Das > --- > drivers/scsi/ufs/ufshcd.c | 28 ++++++++++++++++++++-------- > drivers/scsi/ufs/ufshcd.h | 2 ++ > 2 files changed, 22 insertions(+), 8 deletions(-) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index dfeb194..c35a076 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -264,6 +264,18 @@ static inline void ufshcd_disable_irq(struct > ufs_hba *hba) > } > } > > +static void ufshcd_scsi_unblock_requests(struct ufs_hba *hba) > +{ > + if (atomic_dec_and_test(&hba->scsi_block_reqs_cnt)) > + scsi_unblock_requests(hba->host); > +} > + > +static void ufshcd_scsi_block_requests(struct ufs_hba *hba) > +{ > + if (atomic_inc_return(&hba->scsi_block_reqs_cnt) == 1) > + scsi_block_requests(hba->host); > +} > + > /* replace non-printable or non-ASCII characters with spaces */ > static inline void ufshcd_remove_non_printable(char *val) > { > @@ -1077,12 +1089,12 @@ static int ufshcd_clock_scaling_prepare(struct > ufs_hba *hba) > * make sure that there are no outstanding requests when > * clock scaling is in progress > */ > - scsi_block_requests(hba->host); > + ufshcd_scsi_block_requests(hba); > down_write(&hba->clk_scaling_lock); > if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US)) { > ret = -EBUSY; > up_write(&hba->clk_scaling_lock); > - scsi_unblock_requests(hba->host); > + ufshcd_scsi_unblock_requests(hba); > } > > return ret; > @@ -1091,7 +1103,7 @@ static int ufshcd_clock_scaling_prepare(struct > ufs_hba *hba) > static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba) > { > up_write(&hba->clk_scaling_lock); > - scsi_unblock_requests(hba->host); > + ufshcd_scsi_unblock_requests(hba); > } > > /** > @@ -1411,7 +1423,7 @@ static void ufshcd_ungate_work(struct work_struct > *work) > hba->clk_gating.is_suspended = false; > } > unblock_reqs: > - scsi_unblock_requests(hba->host); > + ufshcd_scsi_unblock_requests(hba); > } > > /** > @@ -1467,7 +1479,7 @@ int ufshcd_hold(struct ufs_hba *hba, bool async) > * work and to enable clocks. > */ > case CLKS_OFF: > - scsi_block_requests(hba->host); > + ufshcd_scsi_block_requests(hba); > hba->clk_gating.state = REQ_CLKS_ON; > trace_ufshcd_clk_gating(dev_name(hba->dev), > hba->clk_gating.state); > @@ -5192,7 +5204,7 @@ static void ufshcd_err_handler(struct work_struct > *work) > > out: > spin_unlock_irqrestore(hba->host->host_lock, flags); > - scsi_unblock_requests(hba->host); > + ufshcd_scsi_unblock_requests(hba); > ufshcd_release(hba); > pm_runtime_put_sync(hba->dev); > } > @@ -5294,7 +5306,7 @@ static void ufshcd_check_errors(struct ufs_hba > *hba) > /* handle fatal errors only when link is functional */ > if (hba->ufshcd_state == UFSHCD_STATE_OPERATIONAL) { > /* block commands from scsi mid-layer */ > - scsi_block_requests(hba->host); > + ufshcd_scsi_block_requests(hba); > > hba->ufshcd_state = UFSHCD_STATE_EH_SCHEDULED; > > @@ -8017,7 +8029,7 @@ int ufshcd_init(struct ufs_hba *hba, void > __iomem *mmio_base, unsigned int irq) > > /* Hold auto suspend until async scan completes */ > pm_runtime_get_sync(dev); > - > + atomic_set(&hba->scsi_block_reqs_cnt, 0); > /* > * We are assuming that device wasn't put in sleep/power-down > * state exclusively during the boot stage before kernel. > diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h > index 0417c42..76c31d5 100644 > --- a/drivers/scsi/ufs/ufshcd.h > +++ b/drivers/scsi/ufs/ufshcd.h > @@ -498,6 +498,7 @@ struct ufs_stats { > * @urgent_bkops_lvl: keeps track of urgent bkops level for device > * @is_urgent_bkops_lvl_checked: keeps track if the urgent bkops level > for > * device is known or not. > + * @scsi_block_reqs_cnt: reference counting for scsi block requests > */ > struct ufs_hba { > void __iomem *mmio_base; > @@ -698,6 +699,7 @@ struct ufs_hba { > > struct rw_semaphore clk_scaling_lock; > struct ufs_desc_size desc_size; > + atomic_t scsi_block_reqs_cnt; > }; > > /* Returns true if clocks can be gated. Otherwise false */ Looks good to me. -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project