Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp303729pxj; Wed, 23 Jun 2021 22:53:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyN0SMj3U9ZR0U8kyNJVgUCajVG2Fj16pYEJxpGjlQbvj7waen7P3T6NJXxnd3Or+1+vXXM X-Received: by 2002:a6b:510f:: with SMTP id f15mr2776355iob.10.1624514032365; Wed, 23 Jun 2021 22:53:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624514032; cv=none; d=google.com; s=arc-20160816; b=t8N/097CCVYE/GHw1G5wDeSRzxe0K2+JSVZzMaGn6mOH5M++FKr4E/5EanrEj6tXPN G1kz1K71SHwp8IBq9NCkYbc9H1zGO9SXP5TvIK7i+7AWROB2bN8fv3ZE/w0RMU2qKZwr ocZOhANg4UTFjm21oONv6QKoARauvgDt/J6CpeRmjSNbF7nZYN+BaLN3ZXRZyY4Sjbcx VS/LsQCUCMCQes1dVYDISo9DY6Isy61qEK3azwX0hQ+Slw10LETVA6EyI9FQXhtjeqrv NT9dDqFicebVmThCGCWniN7NzKcADqDK3yjw/04BVKLtvNtyAifLbylboqqcr3jS5HYI PnYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:ironport-sdr:ironport-sdr; bh=ilfhHg66qlUVxv2i1S4728XSdtHCjvEJ6ROvuW4Q5Fo=; b=CO4mvm6RtlQ85TwzoHqSGQBgLoYv5ZEgRBNeSnGSAOX6oKv4kxjXozqHsSgjOWj1xG i8TY+S9cisHGnSvLecWFUmDAEah0E/G+XCT8MPhLkMFBDGm6Mg+BHhpYQ7WDp9LCV+W6 PlK6K8wRWzNuRj0ItqYwgeKIEmIKi+wT98rMEkccmBDBA/OBrsRY9LmGEL4YOPDd03l4 R+hJpLHFZpXydnBjXGBz5kljhwODRJtj8B9g5UX6eM/QX7EZeSOOTnpNAEATf621oX8N /3SueU+G5UkyA/s4wzDpYutGXbfZ030YzbNoXMSf0Lz9qZs/sI6HIma5bJ/zcdnq1WV6 bx7Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e1si1855797ilq.159.2021.06.23.22.53.40; Wed, 23 Jun 2021 22:53:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230257AbhFXFyr (ORCPT + 99 others); Thu, 24 Jun 2021 01:54:47 -0400 Received: from mga11.intel.com ([192.55.52.93]:13025 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230490AbhFXFym (ORCPT ); Thu, 24 Jun 2021 01:54:42 -0400 IronPort-SDR: xB/0foU3Fp3R8n37Ulc4FPZsf43wweObL3EJi/xvkyM0eCPqwAcFYZpP1/DtKRl/e+GylkG0BP G54MNVQ8adtA== X-IronPort-AV: E=McAfee;i="6200,9189,10024"; a="204393799" X-IronPort-AV: E=Sophos;i="5.83,295,1616482800"; d="scan'208";a="204393799" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2021 22:52:06 -0700 IronPort-SDR: ui/P9D01LSr2z7kxpyRmG7ZclFxhQZDgisqApsmdsNwLeZt4FdNTDlW8uw45D6Z/cU8PTyTKS9 7Mo2a5IUlVbw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,295,1616482800"; d="scan'208";a="406531260" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.79]) ([10.237.72.79]) by orsmga006.jf.intel.com with ESMTP; 23 Jun 2021 22:52:02 -0700 Subject: Re: [PATCH v4 06/10] scsi: ufs: Remove host_sem used in suspend/resume To: Can Guo Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org, hongwus@codeaurora.org, ziqichen@codeaurora.org, linux-scsi@vger.kernel.org, kernel-team@android.com, Alim Akhtar , Avri Altman , "James E.J. Bottomley" , "Martin K. Petersen" , Stanley Chu , Bean Huo , Jaegeuk Kim , open list References: <1624433711-9339-1-git-send-email-cang@codeaurora.org> <1624433711-9339-8-git-send-email-cang@codeaurora.org> <9105f328ee6ce916a7f01027b0d28332@codeaurora.org> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: Date: Thu, 24 Jun 2021 08:52:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <9105f328ee6ce916a7f01027b0d28332@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/06/21 5:16 am, Can Guo wrote: > On 2021-06-23 22:30, Adrian Hunter wrote: >> On 23/06/21 10:35 am, Can Guo wrote: >>> To protect system suspend/resume from being disturbed by error handling, >>> instead of using host_sem, let error handler call lock_system_sleep() and >>> unlock_system_sleep() which achieve the same purpose. Remove the host_sem >>> used in suspend/resume paths to make the code more readable. >>> >>> Suggested-by: Bart Van Assche >>> Signed-off-by: Can Guo >>> --- >>>  drivers/scsi/ufs/ufshcd.c | 12 +++++++----- >>>  1 file changed, 7 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c >>> index 3695dd2..a09e4a2 100644 >>> --- a/drivers/scsi/ufs/ufshcd.c >>> +++ b/drivers/scsi/ufs/ufshcd.c >>> @@ -5907,6 +5907,11 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend) >>> >>>  static void ufshcd_err_handling_prepare(struct ufs_hba *hba) >>>  { >>> +    /* >>> +     * It is not safe to perform error handling while suspend or resume is >>> +     * in progress. Hence the lock_system_sleep() call. >>> +     */ >>> +    lock_system_sleep(); >> >> It looks to me like the system takes this lock quite early, even before >> freezing tasks, so if anything needs the error handler to run it will >> deadlock. > > Hi Adrian, > > UFS/hba system suspend/resume does not invoke or call error handling in a > synchronous way. So, whatever UFS errors (which schedules the error handler) > happens during suspend/resume, error handler will just wait here till system > suspend/resume release the lock. Hence no worries of deadlock here. It looks to me like the state can change to UFSHCD_STATE_EH_SCHEDULED_FATAL and since user processes are not frozen, nor file systems sync'ed, everything is going to deadlock. i.e. I/O is blocked waiting on error handling error handling is blocked waiting on lock_system_sleep() suspend is blocked waiting on I/O > > Thanks, > > Can Guo. > >> >>>      ufshcd_rpm_get_sync(hba); >>>      if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) || >>>          hba->is_wlu_sys_suspended) { >>> @@ -5951,6 +5956,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba) >>>          ufshcd_clk_scaling_suspend(hba, false); >>>      ufshcd_clear_ua_wluns(hba); >>>      ufshcd_rpm_put(hba); >>> +    unlock_system_sleep(); >>>  } >>> >>>  static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba) >>> @@ -9053,16 +9059,13 @@ static int ufshcd_wl_suspend(struct device *dev) >>>      ktime_t start = ktime_get(); >>> >>>      hba = shost_priv(sdev->host); >>> -    down(&hba->host_sem); >>> >>>      if (pm_runtime_suspended(dev)) >>>          goto out; >>> >>>      ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM); >>> -    if (ret) { >>> +    if (ret) >>>          dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret); >>> -        up(&hba->host_sem); >>> -    } >>> >>>  out: >>>      if (!ret) >>> @@ -9095,7 +9098,6 @@ static int ufshcd_wl_resume(struct device *dev) >>>          hba->curr_dev_pwr_mode, hba->uic_link_state); >>>      if (!ret) >>>          hba->is_wlu_sys_suspended = false; >>> -    up(&hba->host_sem); >>>      return ret; >>>  } >>>  #endif >>>