Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2514471imm; Wed, 16 May 2018 14:15:36 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrpqKAheanT7r0M0u7OCn0DBxaHhOZckRFYUuSoA3zOR0Eq8yDd+HW6bjY45Vuxd/Ll2xZT X-Received: by 2002:a65:534b:: with SMTP id w11-v6mr1965053pgr.79.1526505336574; Wed, 16 May 2018 14:15:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526505336; cv=none; d=google.com; s=arc-20160816; b=p8AyUfZwGjWN2dKatlKjOW6tBfaHtwIStqN9h2inkhp0NwodUlwEw7jfCvFji3k/gs ScT9HrouqqOB506Jni3Q7tahg0yIR87Y9+ofdnq7ijtSCREp6AnuCSomBeFMWkQlpXpm uGN2fSPf4PxqXtfxMAARh3DQw9rGsLhRH/VBPNqqEi6nuSf+zuSCg2++zF1DOmomC2ja mtqJQEPWGzOIpbMPR6EaoSlc9EoKtmrVCiGn9G/6yb8YajTa0iUS1Rs52IzTSKJlpVN6 fDSKeaK5OmBnMKU5CVCb35Oj+7aarKrO31aVqGnypsOPSeZXPvz0GPXhkRTF56kmlPCF IcMA== 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=f4QmwgT7oyKzEMTNhRwzW1+55Ufnq0oD/iJAECLw5+A=; b=0MRzmJRQn5sHUpUZZnqFwLb3BvpaO0LCJG9tp7VERmQeBp0gSgV8/K2V6ZGTATtUiJ HgCRqURArXZJN+A3b6OFstHi7j8y6jglRINU5lTbgHURYwYgDxmDFZSl1BTAWId7wLS0 6RtunMKTGuMiOPLUsn0zM1e20SF/i0XEaWnpBNduBKTLMsoFVUyY6p/8kOGiCYpeJF7z 7/1ijKgTOik5PBdxbD6AIVU+XdrDIm+y5ttfU95Waq3AzE3F3MCV7yTTbNrx5FBupKer sADyuxk/WP23amFAzb2Zp/kD2qzLiRfCs4lQQ245h3VkuBznSKxyAPB4roCnR8VIk8Js O3wQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=l9m2Psnw; dkim=pass header.i=@codeaurora.org header.s=default header.b=iNA/MKQM; 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 31-v6si3385421pli.404.2018.05.16.14.15.21; Wed, 16 May 2018 14:15:36 -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=l9m2Psnw; dkim=pass header.i=@codeaurora.org header.s=default header.b=iNA/MKQM; 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 S1752381AbeEPVOr (ORCPT + 99 others); Wed, 16 May 2018 17:14:47 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:56618 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752059AbeEPVOp (ORCPT ); Wed, 16 May 2018 17:14:45 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id B6F51605FD; Wed, 16 May 2018 21:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526505284; bh=jsTTbOksd+v4RdiiJp1qQLRlS4YVCb7irzTeRhlQWsg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=l9m2PsnwSkSCr68u91dosPKPZnGt7hba+D34fogskDS9VZNQdBOHh3QI1CTng/jdY kpKnzQgm5pzpVrT3y5A75Dw9zpK1jgrZC6es8LAGfRueBSqwvgy9dGdEMEnp7eHsi5 D22FiCT+cbi49LTduZ4885ZgpzcWF2nPPRdqvqhY= 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 987A260209; Wed, 16 May 2018 21:14:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526505283; bh=jsTTbOksd+v4RdiiJp1qQLRlS4YVCb7irzTeRhlQWsg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iNA/MKQMwdCyX76Grlvq47Cb/Mcd/dBi318rFVU6U0G49VKl4D3r6vJEmo4pomBRp /oSLiEddCok/z96WcholrKwSzR4H4TbDUvE2szzS2GQ5jGYI3FiTfAkmeQM4vRIrua uuVFVzQ8pXE3kpLFj2cp8kmzzHHIC+WR0Tyds4qA= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 May 2018 14:14:43 -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, Vijay Viswanath , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi-owner@vger.kernel.org Subject: Re: [PATCH v2 10/10] scsi: ufs: Add clock ungating to a separate workqueue In-Reply-To: <0bfae28dbfb4cf86e80435639b92c7f4023041dc.1525343531.git.asutoshd@codeaurora.org> References: <0bfae28dbfb4cf86e80435639b92c7f4023041dc.1525343531.git.asutoshd@codeaurora.org> Message-ID: <9b3fe3b9f1bd2f7c36dcd840acf7848d@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: Vijay Viswanath > > UFS driver can receive a request during memory reclaim by kswapd. > So when ufs driver puts the ungate work in queue, and if there are no > idle workers, kthreadd is invoked to create a new kworker. Since > kswapd task holds a mutex which kthreadd also needs, this can cause > a deadlock situation. So ungate work must be done in a separate > work queue with WQ_MEM_RECLAIM flag enabled. > Such a workqueue will have a rescue thread which will be called > when the above deadlock condition is possible. > > Signed-off-by: Vijay Viswanath > Signed-off-by: Can Guo > Signed-off-by: Asutosh Das > --- > drivers/scsi/ufs/ufshcd.c | 11 ++++++++++- > drivers/scsi/ufs/ufshcd.h | 1 + > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index 557d538..3be61b7 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -1483,7 +1483,8 @@ int ufshcd_hold(struct ufs_hba *hba, bool async) > hba->clk_gating.state = REQ_CLKS_ON; > trace_ufshcd_clk_gating(dev_name(hba->dev), > hba->clk_gating.state); > - schedule_work(&hba->clk_gating.ungate_work); > + queue_work(hba->clk_gating.clk_gating_workq, > + &hba->clk_gating.ungate_work); > /* > * fall through to check if we should wait for this > * work to be done or not. > @@ -1669,6 +1670,8 @@ static ssize_t > ufshcd_clkgate_enable_store(struct device *dev, > > static void ufshcd_init_clk_gating(struct ufs_hba *hba) > { > + char wq_name[sizeof("ufs_clk_gating_00")]; > + > if (!ufshcd_is_clkgating_allowed(hba)) > return; > > @@ -1676,6 +1679,11 @@ static void ufshcd_init_clk_gating(struct > ufs_hba *hba) > INIT_DELAYED_WORK(&hba->clk_gating.gate_work, ufshcd_gate_work); > INIT_WORK(&hba->clk_gating.ungate_work, ufshcd_ungate_work); > > + snprintf(wq_name, ARRAY_SIZE(wq_name), "ufs_clk_gating_%d", > + hba->host->host_no); > + hba->clk_gating.clk_gating_workq = alloc_ordered_workqueue(wq_name, > + WQ_MEM_RECLAIM); > + > hba->clk_gating.is_enabled = true; > > hba->clk_gating.delay_attr.show = ufshcd_clkgate_delay_show; > @@ -1703,6 +1711,7 @@ static void ufshcd_exit_clk_gating(struct ufs_hba > *hba) > device_remove_file(hba->dev, &hba->clk_gating.enable_attr); > cancel_work_sync(&hba->clk_gating.ungate_work); > cancel_delayed_work_sync(&hba->clk_gating.gate_work); > + destroy_workqueue(hba->clk_gating.clk_gating_workq); > } > > /* Must be called with host lock acquired */ > diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h > index 76c31d5..2e6bdc0 100644 > --- a/drivers/scsi/ufs/ufshcd.h > +++ b/drivers/scsi/ufs/ufshcd.h > @@ -361,6 +361,7 @@ struct ufs_clk_gating { > struct device_attribute enable_attr; > bool is_enabled; > int active_reqs; > + struct workqueue_struct *clk_gating_workq; > }; > > struct ufs_saved_pwr_info { Looks good to me. Reviewed-by: Subhash Jadavani -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project