Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3206177ybv; Sun, 9 Feb 2020 17:59:50 -0800 (PST) X-Google-Smtp-Source: APXvYqzWe5HLt9FBAKZShKLSLEpE169JYCGeyoKCRQ9w8+49l8wvfoGy2ToPTcptkgmyFLgev1cN X-Received: by 2002:a9d:bb8:: with SMTP id 53mr7099920oth.150.1581299990285; Sun, 09 Feb 2020 17:59:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581299990; cv=none; d=google.com; s=arc-20160816; b=UkmvxkIKNxVH87va3PYhdIX0trKbCU8LmdgU9Viugs13ZF3BPIm17LDutHhnkrlMKi kuOEvM0WtBQnJBWDMgo6Uq1BMFQfZNjBx2a1UJaE9koypRqcU/kOop0pgo1QtJ+fCbtV glwPHtaSyswPNX3cXah6xfbiZAluEkpoGzLHQRASmZ0M5aIv/mUImHEH3vXEvUsOHbvY xVZCej4tnpgHBRf12pFOmc4tHhBOQBu8DppCIuaEyG7aaZ/q8zolUgufw/Fgot99y3cg UG9oTG+c/WUpwOUvzrbrc2onV2PjovkHKANeoggqrFpxQStLn+vjPi7PqkCnx8HPH9N0 ZI3A== 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; bh=N2ueIASSsPG9v5/Y5fOzat7g9SFpFYPheldlsYo4p6w=; b=VluB/4OfqFPS3bl+IRegKKxKHuxgd5h/6NmA9Ma1ZQtPhbta6koHRfl/bvNcIfOQ/X Z2ZOivXJ/uTblD8U23FzYfPlXtRy/cwiFSsaNaqfgplW2I5F+tA00ZGu6xAGfUQj9Dmk KWSYbvOX2msmp5TtyJMM5AW7WRx07rEZLxVNzovFbJd33KeyKRGe0I5qJ5/Ej53Wh/bc 9mBZ/I0JLY2DNMsnuyKWBkFXKQexUQL3FSOOG8EWKFRlCgWSpLl55D1S2LRDrPjhgVx7 wZzI0y8tX6/NzUA83kwQVIVQ1F4uYQTxev0CM8GxNGVY5q20dw6EkCWE4gGtTHfhpuT3 Qwfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=Z0O73LDg; 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 t128si7812152oie.176.2020.02.09.17.59.38; Sun, 09 Feb 2020 17:59:50 -0800 (PST) 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=fail header.i=@mg.codeaurora.org header.s=smtp header.b=Z0O73LDg; 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 S1726944AbgBJB7a (ORCPT + 99 others); Sun, 9 Feb 2020 20:59:30 -0500 Received: from mail26.static.mailgun.info ([104.130.122.26]:62912 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726418AbgBJB7a (ORCPT ); Sun, 9 Feb 2020 20:59:30 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1581299969; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=N2ueIASSsPG9v5/Y5fOzat7g9SFpFYPheldlsYo4p6w=; b=Z0O73LDgiEje+uQGBqVHlaP2e7ysUcNFYxrP5iF4hzfXR9kTmv5bXyuwfNQ7hgL6apsjU/GM bYT6NMOohI67NfwQkFNh9sGL3CpaqkVVHAOi+Fvoxa7laGv1Ksue8xYzhRLGBfVAJQRcfMOs lf0Z8ofUxGz4Z6EwFFSxn7WpMUY= X-Mailgun-Sending-Ip: 104.130.122.26 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5e40b8fb.7fc587f09fb8-smtp-out-n03; Mon, 10 Feb 2020 01:59:23 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id EB423C447A9; Mon, 10 Feb 2020 01:59:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cang) by smtp.codeaurora.org (Postfix) with ESMTPSA id 1B00AC43383; Mon, 10 Feb 2020 01:59:20 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 10 Feb 2020 09:59:20 +0800 From: Can Guo To: Avri Altman Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, rnayak@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, saravanak@google.com, salyzyn@google.com, Alim Akhtar , "James E.J. Bottomley" , "Martin K. Petersen" , Matthias Brugger , Bean Huo , Stanley Chu , Bart Van Assche , Venkat Gopalakrishnan , Tomas Winkler , open list , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" Subject: Re: [PATCH v7 5/8] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic In-Reply-To: <2c485ce3fac4d92ab3776daecc1af493@codeaurora.org> References: <1580978008-9327-1-git-send-email-cang@codeaurora.org> <1580978008-9327-6-git-send-email-cang@codeaurora.org> <2c485ce3fac4d92ab3776daecc1af493@codeaurora.org> Message-ID: X-Sender: cang@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-02-10 09:28, Can Guo wrote: > On 2020-02-06 18:28, Avri Altman wrote: >> Hi, >> >>> >>> The async version of ufshcd_hold(async == true), which is only called >>> in queuecommand path as for now, is expected to work in atomic >>> context, >>> thus it should not sleep or schedule out. When it runs into the >>> condition >>> that clocks are ON but link is still in hibern8 state, it should bail >>> out >>> without flushing the clock ungate work. >> >> Fixes: f2a785ac2312 (scsi: ufshcd: Fix race between clk scaling and >> ungate work) > > Sorry, missed this one, if another version is needed, I will add this > line. > >>> >>> Signed-off-by: Can Guo >>> Reviewed-by: Hongwu Su >>> Reviewed-by: Asutosh Das >>> Reviewed-by: Bean Huo >>> Reviewed-by: Stanley Chu >>> --- >>> drivers/scsi/ufs/ufshcd.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c >>> index bbc2607..e8f7f9d 100644 >>> --- a/drivers/scsi/ufs/ufshcd.c >>> +++ b/drivers/scsi/ufs/ufshcd.c >>> @@ -1518,6 +1518,11 @@ int ufshcd_hold(struct ufs_hba *hba, bool >>> async) >>> */ >>> if (ufshcd_can_hibern8_during_gating(hba) && >>> ufshcd_is_link_hibern8(hba)) { >>> + if (async) { >>> + rc = -EAGAIN; >>> + hba->clk_gating.active_reqs--; >>> + break; >>> + } >>> spin_unlock_irqrestore(hba->host->host_lock, >>> flags); >>> flush_work(&hba->clk_gating.ungate_work); >>> spin_lock_irqsave(hba->host->host_lock, >>> flags); >> Since now the above code is shared in all cases, >> Maybe find a more economical way to pack it? >> >> Thanks, >> Avri >> >> > > There are only 2 of this same code pieces in ufshcd_hold() and located > in different cases, meanwhile there can be fall through, I don't see > a good way to pack it, can you suggest if you have any ideas? > Now, with this patch, there are 2 same code snippets located in CLKS_ON and REQ_CLKS_ON. If we somehow pack them, say bring in a inline func to pack them, we would have to tear it down later if we have to fix something for only one specific case by adding lines into the snippet. And actually this is the truth, we do have some fixes for CLKS_ON's case but not yet uploaded, so let's leave it as it is for now. > Regards, > Can Guo. > >>> -- >>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >>> Forum, >>> a Linux Foundation Collaborative Project