| Message ID | 1621845419-14194-3-git-send-email-cang@codeaurora.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Optimize host lock on TR send/compl paths and utilize UTRLCNR | expand |
Hi Can,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on next-20210524]
[cannot apply to scsi/for-next v5.13-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Can-Guo/Optimize-host-lock-on-TR-send-compl-paths-and-utilize-UTRLCNR/20210524-163847
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
config: arm64-randconfig-r011-20210524 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 93d1e5822ed64abd777eb94ea9899e96c4c39fbe)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# https://github.com/0day-ci/linux/commit/efe94162bf7973be4ed6496871b9bc9ea54e2819
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Can-Guo/Optimize-host-lock-on-TR-send-compl-paths-and-utilize-UTRLCNR/20210524-163847
git checkout efe94162bf7973be4ed6496871b9bc9ea54e2819
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/scsi/ufs/ufshcd.c:2959:6: warning: variable 'lrbp' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (unlikely(test_bit(tag, &hba->outstanding_reqs))) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/compiler.h:78:22: note: expanded from macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/ufs/ufshcd.c:2981:32: note: uninitialized use occurs here
(struct utp_upiu_req *)lrbp->ucd_rsp_ptr);
^~~~
drivers/scsi/ufs/ufshcd.c:2959:2: note: remove the 'if' if its condition is always false
if (unlikely(test_bit(tag, &hba->outstanding_reqs))) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/ufs/ufshcd.c:2939:25: note: initialize the variable 'lrbp' to silence this warning
struct ufshcd_lrb *lrbp;
^
= NULL
1 warning generated.
vim +2959 drivers/scsi/ufs/ufshcd.c
2924
2925 /**
2926 * ufshcd_exec_dev_cmd - API for sending device management requests
2927 * @hba: UFS hba
2928 * @cmd_type: specifies the type (NOP, Query...)
2929 * @timeout: time in seconds
2930 *
2931 * NOTE: Since there is only one available tag for device management commands,
2932 * it is expected you hold the hba->dev_cmd.lock mutex.
2933 */
2934 static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
2935 enum dev_cmd_type cmd_type, int timeout)
2936 {
2937 struct request_queue *q = hba->cmd_queue;
2938 struct request *req;
2939 struct ufshcd_lrb *lrbp;
2940 int err;
2941 int tag;
2942 struct completion wait;
2943
2944 down_read(&hba->clk_scaling_lock);
2945
2946 /*
2947 * Get free slot, sleep if slots are unavailable.
2948 * Even though we use wait_event() which sleeps indefinitely,
2949 * the maximum wait time is bounded by SCSI request timeout.
2950 */
2951 req = blk_get_request(q, REQ_OP_DRV_OUT, 0);
2952 if (IS_ERR(req)) {
2953 err = PTR_ERR(req);
2954 goto out_unlock;
2955 }
2956 tag = req->tag;
2957 WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag));
2958
> 2959 if (unlikely(test_bit(tag, &hba->outstanding_reqs))) {
2960 err = -EBUSY;
2961 goto out;
2962 }
2963
2964 init_completion(&wait);
2965 lrbp = &hba->lrb[tag];
2966 WARN_ON(lrbp->cmd);
2967 err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag);
2968 if (unlikely(err))
2969 goto out_put_tag;
2970
2971 hba->dev_cmd.complete = &wait;
2972
2973 ufshcd_add_query_upiu_trace(hba, UFS_QUERY_SEND, lrbp->ucd_req_ptr);
2974 /* Make sure descriptors are ready before ringing the doorbell */
2975 wmb();
2976
2977 ufshcd_send_command(hba, tag);
2978 err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout);
2979 out:
2980 ufshcd_add_query_upiu_trace(hba, err ? UFS_QUERY_ERR : UFS_QUERY_COMP,
2981 (struct utp_upiu_req *)lrbp->ucd_rsp_ptr);
2982
2983 out_put_tag:
2984 blk_put_request(req);
2985 out_unlock:
2986 up_read(&hba->clk_scaling_lock);
2987 return err;
2988 }
2989
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
On 5/24/21 1:36 AM, Can Guo wrote: > Current UFS IRQ handler is completely wrapped by host lock, and because > ufshcd_send_command() is also protected by host lock, when IRQ handler > fires, not only the CPU running the IRQ handler cannot send new requests, > the rest CPUs can neither. Move the host lock wrapping the IRQ handler into > specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(), > ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to further > reduce occpuation of host lock in ufshcd_transfer_req_compl(), host lock is > no longer required to call __ufshcd_transfer_req_compl(). As per test, the > optimization can bring considerable gain to random read/write performance. Hi Can, Using the host lock to serialize the completion path against the submission path was a common practice 11 years ago, before the host lock push-down (see also https://linux-scsi.vger.kernel.narkive.com/UEmGgwAc/rfc-patch-scsi-host-lock-push-down). Modern SCSI LLDs should not use the SCSI host lock. Please consider introducing one or more new synchronization objects in struct ufs_hba and to use these instead of the SCSI host lock. That will save multiple pointer dereferences in the hot path since hba->host->host_lock will become hba->new_spin_lock. An additional question is whether it is necessary for v3.0 UFS devices to serialize the submission path against the completion path? Multiple high-performance SCSI LLDs support hardware with separate submission and completion queues and hence do not need any serialization between the submission and the completion path. I'm asking this because it is likely that sooner or later multiqueue support will be added in the UFS specification. Benefiting from multiqueue support will require to rework locking in the UFS driver anyway. Thanks, Bart.
On 5/24/2021 1:10 PM, Bart Van Assche wrote: > On 5/24/21 1:36 AM, Can Guo wrote: >> Current UFS IRQ handler is completely wrapped by host lock, and because >> ufshcd_send_command() is also protected by host lock, when IRQ handler >> fires, not only the CPU running the IRQ handler cannot send new requests, >> the rest CPUs can neither. Move the host lock wrapping the IRQ handler into >> specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(), >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to further >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host lock is >> no longer required to call __ufshcd_transfer_req_compl(). As per test, the >> optimization can bring considerable gain to random read/write performance. > > An additional question is whether it is necessary for v3.0 UFS devices > to serialize the submission path against the completion path? Multiple > high-performance SCSI LLDs support hardware with separate submission and > completion queues and hence do not need any serialization between the > submission and the completion path. I'm asking this because it is likely > that sooner or later multiqueue support will be added in the UFS > specification. Benefiting from multiqueue support will require to rework > locking in the UFS driver anyway. > Hi Bart, No it's not necessary to serialize both the paths. I think this series attempts to remove this serialization to a certain degree, which is what's giving the performance improvement. Even if multiqueue support would be available in the future, I think this change is apt now for the current available specification. > Thanks, > > Bart. > Thanks, -asd
On 2021-05-25 04:10, Bart Van Assche wrote: > On 5/24/21 1:36 AM, Can Guo wrote: >> Current UFS IRQ handler is completely wrapped by host lock, and >> because >> ufshcd_send_command() is also protected by host lock, when IRQ handler >> fires, not only the CPU running the IRQ handler cannot send new >> requests, >> the rest CPUs can neither. Move the host lock wrapping the IRQ handler >> into >> specific branches, i.e., ufshcd_uic_cmd_compl(), >> ufshcd_check_errors(), >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to >> further >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host >> lock is >> no longer required to call __ufshcd_transfer_req_compl(). As per test, >> the >> optimization can bring considerable gain to random read/write >> performance. > > Hi Can, > > Using the host lock to serialize the completion path against the > submission path was a common practice 11 years ago, before the host > lock > push-down (see also > https://linux-scsi.vger.kernel.narkive.com/UEmGgwAc/rfc-patch-scsi-host-lock-push-down). > Modern SCSI LLDs should not use the SCSI host lock. Please consider > introducing one or more new synchronization objects in struct ufs_hba > and to use these instead of the SCSI host lock. That will save multiple > pointer dereferences in the hot path since hba->host->host_lock will > become hba->new_spin_lock. > > An additional question is whether it is necessary for v3.0 UFS devices > to serialize the submission path against the completion path? Multiple > high-performance SCSI LLDs support hardware with separate submission > and > completion queues and hence do not need any serialization between the > submission and the completion path. I'm asking this because it is > likely > that sooner or later multiqueue support will be added in the UFS > specification. Benefiting from multiqueue support will require to > rework > locking in the UFS driver anyway. > Hi Bart, Agree with all above, and what you ask is right what we are doing in the 3rd change - get rid of host lock on dispatch and completion paths. I agree with using dedicated spin locks for dedicated purposes in UFS driver, e.g., clk gating has its own gating_lock and clk scaling has its own scaling_lock. But this specific series is only for improving performance. We will take your comments into consideration and address it in future. Thanks, Can Guo. > Thanks, > > Bart.
> On 5/24/2021 1:10 PM, Bart Van Assche wrote: > > On 5/24/21 1:36 AM, Can Guo wrote: > >> Current UFS IRQ handler is completely wrapped by host lock, and because > >> ufshcd_send_command() is also protected by host lock, when IRQ handler > >> fires, not only the CPU running the IRQ handler cannot send new > requests, > >> the rest CPUs can neither. Move the host lock wrapping the IRQ handler > into > >> specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(), > >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to > further > >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host lock > is > >> no longer required to call __ufshcd_transfer_req_compl(). As per test, the > >> optimization can bring considerable gain to random read/write > performance. > > > > > An additional question is whether it is necessary for v3.0 UFS devices > > to serialize the submission path against the completion path? Multiple > > high-performance SCSI LLDs support hardware with separate submission > and > > completion queues and hence do not need any serialization between the > > submission and the completion path. I'm asking this because it is likely > > that sooner or later multiqueue support will be added in the UFS > > specification. Benefiting from multiqueue support will require to rework > > locking in the UFS driver anyway. > > > Hi Bart, > No it's not necessary to serialize both the paths. I think this series > attempts to remove this serialization to a certain degree, which is > what's giving the performance improvement. > > Even if multiqueue support would be available in the future, I think > this change is apt now for the current available specification. I agree - this looks like the harbinger of a major change, And going further with respect of hw queues, will need the spec support - e.g. doorbell per lane, etc. Thanks, Avri > > Thanks, > > > > Bart. > > > > > Thanks, > -asd > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora > Forum, > Linux Foundation Collaborative Project
On 5/24/21 6:40 PM, Can Guo wrote: > Agree with all above, and what you ask is right what we are doing in > the 3rd change - get rid of host lock on dispatch and completion > paths. > > I agree with using dedicated spin locks for dedicated purposes in > UFS driver, e.g., clk gating has its own gating_lock and clk scaling > has its own scaling_lock. But this specific series is only for > improving performance. We will take your comments into consideration > and address it in future. Thanks! Bart.
> > On 5/24/2021 1:10 PM, Bart Van Assche wrote: > > > On 5/24/21 1:36 AM, Can Guo wrote: > > >> Current UFS IRQ handler is completely wrapped by host lock, and > because > > >> ufshcd_send_command() is also protected by host lock, when IRQ > handler > > >> fires, not only the CPU running the IRQ handler cannot send new > > requests, > > >> the rest CPUs can neither. Move the host lock wrapping the IRQ handler > > into > > >> specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(), > > >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to > > further > > >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host > lock > > is > > >> no longer required to call __ufshcd_transfer_req_compl(). As per test, > the > > >> optimization can bring considerable gain to random read/write > > performance. > > > > > > > > An additional question is whether it is necessary for v3.0 UFS devices > > > to serialize the submission path against the completion path? Multiple > > > high-performance SCSI LLDs support hardware with separate submission > > and > > > completion queues and hence do not need any serialization between the > > > submission and the completion path. I'm asking this because it is likely > > > that sooner or later multiqueue support will be added in the UFS > > > specification. Benefiting from multiqueue support will require to rework > > > locking in the UFS driver anyway. > > > > > Hi Bart, > > No it's not necessary to serialize both the paths. I think this series > > attempts to remove this serialization to a certain degree, which is > > what's giving the performance improvement. Btw, Is this performance improvement is on top of rq_affinity 2 or 1? Thanks, Avri > > > > Even if multiqueue support would be available in the future, I think > > this change is apt now for the current available specification. > I agree - this looks like the harbinger of a major change, > And going further with respect of hw queues, > will need the spec support - e.g. doorbell per lane, etc. > > Thanks, > Avri > > > > Thanks, > > > > > > Bart. > > > > > > > > > Thanks, > > -asd > > > > -- > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora > > Forum, > > Linux Foundation Collaborative Project
On Mon, 2021-05-24 at 01:36 -0700, Can Guo wrote: > Current UFS IRQ handler is completely wrapped by host lock, and > because > > ufshcd_send_command() is also protected by host lock, when IRQ > handler > > fires, not only the CPU running the IRQ handler cannot send new > requests, > > the rest CPUs can neither. Move the host lock wrapping the IRQ > handler into > > specific branches, i.e., ufshcd_uic_cmd_compl(), > ufshcd_check_errors(), > > ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to > further > > reduce occpuation of host lock in ufshcd_transfer_req_compl(), host > lock is > > no longer required to call __ufshcd_transfer_req_compl(). As per > test, the > > optimization can bring considerable gain to random read/write > performance. > > > > Cc: Stanley Chu <stanley.chu@mediatek.com> > > Co-developed-by: Asutosh Das <asutoshd@codeaurora.org> > > Signed-off-by: Asutosh Das <asutoshd@codeaurora.org> > > Signed-off-by: Can Guo <cang@codeaurora.org> Can, The patch looks good to me. I did a UFS queue limitation test before, observed that once the queue is full, then the active task number in the queue will get down. For the Nvme, the scenario is the same. You can refer to the slide 23, and slide 24 in the pdf: https://elinux.org/images/6/6c/Linux_Storage_System_Bottleneck_Exploration_V0.3.pdf I don't know if your patch can fix this issue. Unfortunately, I cannot verify UTRLCNR usage flow since my platform is v2.1. But at least my test can prove that the patch doesn't impact the legacy(UFSHCI is less than v3.0) doorbell usage flow. Reviewed-by: Bean Huo <beanhuo@micron.com> Bean
Hi Bean, On 2021-06-01 00:04, Bean Huo wrote: > On Mon, 2021-05-24 at 01:36 -0700, Can Guo wrote: >> Current UFS IRQ handler is completely wrapped by host lock, and >> because >> >> ufshcd_send_command() is also protected by host lock, when IRQ >> handler >> >> fires, not only the CPU running the IRQ handler cannot send new >> requests, >> >> the rest CPUs can neither. Move the host lock wrapping the IRQ >> handler into >> >> specific branches, i.e., ufshcd_uic_cmd_compl(), >> ufshcd_check_errors(), >> >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to >> further >> >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host >> lock is >> >> no longer required to call __ufshcd_transfer_req_compl(). As per >> test, the >> >> optimization can bring considerable gain to random read/write >> performance. >> >> >> >> Cc: Stanley Chu <stanley.chu@mediatek.com> >> >> Co-developed-by: Asutosh Das <asutoshd@codeaurora.org> >> >> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org> >> >> Signed-off-by: Can Guo <cang@codeaurora.org> > > Can, > The patch looks good to me. > I did a UFS queue limitation test before, observed that once the queue > is full, then the active task number in the queue will get down. For > the Nvme, the scenario is the same. You can refer to the slide 23, and > slide 24 in the pdf: > https://elinux.org/images/6/6c/Linux_Storage_System_Bottleneck_Exploration_V0.3.pdf > I don't know if your patch can fix this > issue. I've studied these slides made by you many times, it is really good. I will do some study later on this. Thanks for the slides. > > Unfortunately, I cannot verify UTRLCNR usage flow since my platform is > v2.1. But at least my test can prove that the patch doesn't impact the > legacy(UFSHCI is less than v3.0) doorbell usage flow. > Thanks for your time :). Regards, Can Guo. > Reviewed-by: Bean Huo <beanhuo@micron.com> > > > Bean
On 5/28/2021 12:30 AM, Avri Altman wrote: >>> Hi Bart, >>> No it's not necessary to serialize both the paths. I think this series >>> attempts to remove this serialization to a certain degree, which is >>> what's giving the performance improvement. > Btw, Is this performance improvement is on top of rq_affinity 2 or 1? > It's on 1. > Thanks, > Avri > >>> >>> Even if multiqueue support would be available in the future, I think >>> this change is apt now for the current available specification. >> I agree - this looks like the harbinger of a major change, >> And going further with respect of hw queues, >> will need the spec support - e.g. doorbell per lane, etc. >> >> Thanks, >> Avri >> >>>> Thanks, >>>> >>>> Bart. >>>> >>> >>> >>> Thanks, >>> -asd >>> >>> -- >>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >>> Forum, >>> Linux Foundation Collaborative Project
On 5/31/21 9:04 AM, Bean Huo wrote: > I did a UFS queue limitation test before, observed that once the > queue is full, then the active task number in the queue will get > down. For the Nvme, the scenario is the same. You can refer to the > slide 23, and slide 24 in the pdf: > https://elinux.org/images/6/6c/Linux_Storage_System_Bottleneck_Exploration_V0.3.pdf > I don't know if your patch can fix this issue. Hi Bean, That's a very interesting presentation. Unfortunately the overhead for SCSI in that presentation includes the SCSI core + UFS driver. Given the use of the host lock in the version of the UFS driver that was used to prepare that presentation, the overhead introduced by the UFS driver may be significant. Maybe someone should measure the overhead of the scsi_debug driver and compare it with the NVMe loopback driver to get a better idea of how the overhead of these two subsystems compare to each other? Bart.
Hi Can, On Mon, 2021-05-24 at 01:36 -0700, Can Guo wrote: > Current UFS IRQ handler is completely wrapped by host lock, and because > ufshcd_send_command() is also protected by host lock, when IRQ handler > fires, not only the CPU running the IRQ handler cannot send new requests, > the rest CPUs can neither. Move the host lock wrapping the IRQ handler into > specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(), > ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to further > reduce occpuation of host lock in ufshcd_transfer_req_compl(), host lock is > no longer required to call __ufshcd_transfer_req_compl(). As per test, the > optimization can bring considerable gain to random read/write performance. > > Cc: Stanley Chu <stanley.chu@mediatek.com> > Co-developed-by: Asutosh Das <asutoshd@codeaurora.org> > Signed-off-by: Asutosh Das <asutoshd@codeaurora.org> > Signed-off-by: Can Guo <cang@codeaurora.org> According to my test, the performance indeed has impressive improvement with this series! Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> > #endif > > bool req_abort_skip; > - bool in_use; > }; > > /**
Hi Stanley, On 2021-06-03 10:54, Stanley Chu wrote: > Hi Can, > > On Mon, 2021-05-24 at 01:36 -0700, Can Guo wrote: >> Current UFS IRQ handler is completely wrapped by host lock, and >> because >> ufshcd_send_command() is also protected by host lock, when IRQ handler >> fires, not only the CPU running the IRQ handler cannot send new >> requests, >> the rest CPUs can neither. Move the host lock wrapping the IRQ handler >> into >> specific branches, i.e., ufshcd_uic_cmd_compl(), >> ufshcd_check_errors(), >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to >> further >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host >> lock is >> no longer required to call __ufshcd_transfer_req_compl(). As per test, >> the >> optimization can bring considerable gain to random read/write >> performance. >> >> Cc: Stanley Chu <stanley.chu@mediatek.com> >> Co-developed-by: Asutosh Das <asutoshd@codeaurora.org> >> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org> >> Signed-off-by: Can Guo <cang@codeaurora.org> > > According to my test, the performance indeed has impressive improvement > with this series! > Thanks a lot for your time and review. :) Regards, Can Guo. > Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> > > > > >> #endif >> >> bool req_abort_skip; >> - bool in_use; >> }; >> >> /**
On Mon, May 24, 2021 at 07:25:57PM +0800, kernel test robot wrote: > Hi Can, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on mkp-scsi/for-next] > [also build test WARNING on next-20210524] > [cannot apply to scsi/for-next v5.13-rc3] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: https://github.com/0day-ci/linux/commits/Can-Guo/Optimize-host-lock-on-TR-send-compl-paths-and-utilize-UTRLCNR/20210524-163847 > base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next > config: arm64-randconfig-r011-20210524 (attached as .config) > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 93d1e5822ed64abd777eb94ea9899e96c4c39fbe) > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm64 cross compiling tool for clang build > # apt-get install binutils-aarch64-linux-gnu > # https://github.com/0day-ci/linux/commit/efe94162bf7973be4ed6496871b9bc9ea54e2819 > git remote add linux-review https://github.com/0day-ci/linux > git fetch --no-tags linux-review Can-Guo/Optimize-host-lock-on-TR-send-compl-paths-and-utilize-UTRLCNR/20210524-163847 > git checkout efe94162bf7973be4ed6496871b9bc9ea54e2819 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot <lkp@intel.com> > > All warnings (new ones prefixed by >>): Looks like this build warning never got taken care of before the patch was accepted because I see it on next-20210608. > >> drivers/scsi/ufs/ufshcd.c:2959:6: warning: variable 'lrbp' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] > if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > include/linux/compiler.h:78:22: note: expanded from macro 'unlikely' > # define unlikely(x) __builtin_expect(!!(x), 0) > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/scsi/ufs/ufshcd.c:2981:32: note: uninitialized use occurs here > (struct utp_upiu_req *)lrbp->ucd_rsp_ptr); > ^~~~ > drivers/scsi/ufs/ufshcd.c:2959:2: note: remove the 'if' if its condition is always false > if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/scsi/ufs/ufshcd.c:2939:25: note: initialize the variable 'lrbp' to silence this warning > struct ufshcd_lrb *lrbp; > ^ > = NULL > 1 warning generated. > > > vim +2959 drivers/scsi/ufs/ufshcd.c > > 2924 > 2925 /** > 2926 * ufshcd_exec_dev_cmd - API for sending device management requests > 2927 * @hba: UFS hba > 2928 * @cmd_type: specifies the type (NOP, Query...) > 2929 * @timeout: time in seconds > 2930 * > 2931 * NOTE: Since there is only one available tag for device management commands, > 2932 * it is expected you hold the hba->dev_cmd.lock mutex. > 2933 */ > 2934 static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, > 2935 enum dev_cmd_type cmd_type, int timeout) > 2936 { > 2937 struct request_queue *q = hba->cmd_queue; > 2938 struct request *req; > 2939 struct ufshcd_lrb *lrbp; > 2940 int err; > 2941 int tag; > 2942 struct completion wait; > 2943 > 2944 down_read(&hba->clk_scaling_lock); > 2945 > 2946 /* > 2947 * Get free slot, sleep if slots are unavailable. > 2948 * Even though we use wait_event() which sleeps indefinitely, > 2949 * the maximum wait time is bounded by SCSI request timeout. > 2950 */ > 2951 req = blk_get_request(q, REQ_OP_DRV_OUT, 0); > 2952 if (IS_ERR(req)) { > 2953 err = PTR_ERR(req); > 2954 goto out_unlock; > 2955 } > 2956 tag = req->tag; > 2957 WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); > 2958 > > 2959 if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { > 2960 err = -EBUSY; Should this goto be adjusted to out_put_tag then drop the out label? > 2961 goto out; > 2962 } > 2963 > 2964 init_completion(&wait); > 2965 lrbp = &hba->lrb[tag]; > 2966 WARN_ON(lrbp->cmd); > 2967 err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag); > 2968 if (unlikely(err)) > 2969 goto out_put_tag; > 2970 > 2971 hba->dev_cmd.complete = &wait; > 2972 > 2973 ufshcd_add_query_upiu_trace(hba, UFS_QUERY_SEND, lrbp->ucd_req_ptr); > 2974 /* Make sure descriptors are ready before ringing the doorbell */ > 2975 wmb(); > 2976 > 2977 ufshcd_send_command(hba, tag); > 2978 err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout); > 2979 out: > 2980 ufshcd_add_query_upiu_trace(hba, err ? UFS_QUERY_ERR : UFS_QUERY_COMP, > 2981 (struct utp_upiu_req *)lrbp->ucd_rsp_ptr); > 2982 > 2983 out_put_tag: > 2984 blk_put_request(req); > 2985 out_unlock: > 2986 up_read(&hba->clk_scaling_lock); > 2987 return err; > 2988 } > 2989 > > --- > 0-DAY CI Kernel Test Service, Intel Corporation > https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Cheers, Nathan
Hi Nathan, On 2021-06-09 01:53, Nathan Chancellor wrote: > On Mon, May 24, 2021 at 07:25:57PM +0800, kernel test robot wrote: >> Hi Can, >> >> Thank you for the patch! Perhaps something to improve: >> >> [auto build test WARNING on mkp-scsi/for-next] >> [also build test WARNING on next-20210524] >> [cannot apply to scsi/for-next v5.13-rc3] >> [If your patch is applied to the wrong git tree, kindly drop us a >> note. >> And when submitting patch, we suggest to use '--base' as documented in >> https://git-scm.com/docs/git-format-patch] >> >> url: >> https://github.com/0day-ci/linux/commits/Can-Guo/Optimize-host-lock-on-TR-send-compl-paths-and-utilize-UTRLCNR/20210524-163847 >> base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git >> for-next >> config: arm64-randconfig-r011-20210524 (attached as .config) >> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project >> 93d1e5822ed64abd777eb94ea9899e96c4c39fbe) >> reproduce (this is a W=1 build): >> wget >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross >> -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # install arm64 cross compiling tool for clang build >> # apt-get install binutils-aarch64-linux-gnu >> # >> https://github.com/0day-ci/linux/commit/efe94162bf7973be4ed6496871b9bc9ea54e2819 >> git remote add linux-review https://github.com/0day-ci/linux >> git fetch --no-tags linux-review >> Can-Guo/Optimize-host-lock-on-TR-send-compl-paths-and-utilize-UTRLCNR/20210524-163847 >> git checkout efe94162bf7973be4ed6496871b9bc9ea54e2819 >> # save the attached .config to linux build tree >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross >> ARCH=arm64 >> >> If you fix the issue, kindly add following tag as appropriate >> Reported-by: kernel test robot <lkp@intel.com> >> >> All warnings (new ones prefixed by >>): > > Looks like this build warning never got taken care of before the patch > was accepted because I see it on next-20210608. I am not aware of that it has already accepted to 5.14/scsi-staging. I will fix it with a new patch. > >> >> drivers/scsi/ufs/ufshcd.c:2959:6: warning: variable 'lrbp' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] >> if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> include/linux/compiler.h:78:22: note: expanded from macro >> 'unlikely' >> # define unlikely(x) __builtin_expect(!!(x), 0) >> ^~~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/scsi/ufs/ufshcd.c:2981:32: note: uninitialized use occurs >> here >> (struct utp_upiu_req >> *)lrbp->ucd_rsp_ptr); >> ^~~~ >> drivers/scsi/ufs/ufshcd.c:2959:2: note: remove the 'if' if its >> condition is always false >> if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/scsi/ufs/ufshcd.c:2939:25: note: initialize the variable >> 'lrbp' to silence this warning >> struct ufshcd_lrb *lrbp; >> ^ >> = NULL >> 1 warning generated. >> >> >> vim +2959 drivers/scsi/ufs/ufshcd.c >> >> 2924 >> 2925 /** >> 2926 * ufshcd_exec_dev_cmd - API for sending device management >> requests >> 2927 * @hba: UFS hba >> 2928 * @cmd_type: specifies the type (NOP, Query...) >> 2929 * @timeout: time in seconds >> 2930 * >> 2931 * NOTE: Since there is only one available tag for device >> management commands, >> 2932 * it is expected you hold the hba->dev_cmd.lock mutex. >> 2933 */ >> 2934 static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, >> 2935 enum dev_cmd_type cmd_type, int timeout) >> 2936 { >> 2937 struct request_queue *q = hba->cmd_queue; >> 2938 struct request *req; >> 2939 struct ufshcd_lrb *lrbp; >> 2940 int err; >> 2941 int tag; >> 2942 struct completion wait; >> 2943 >> 2944 down_read(&hba->clk_scaling_lock); >> 2945 >> 2946 /* >> 2947 * Get free slot, sleep if slots are unavailable. >> 2948 * Even though we use wait_event() which sleeps indefinitely, >> 2949 * the maximum wait time is bounded by SCSI request timeout. >> 2950 */ >> 2951 req = blk_get_request(q, REQ_OP_DRV_OUT, 0); >> 2952 if (IS_ERR(req)) { >> 2953 err = PTR_ERR(req); >> 2954 goto out_unlock; >> 2955 } >> 2956 tag = req->tag; >> 2957 WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); >> 2958 >> > 2959 if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { >> 2960 err = -EBUSY; > > Should this goto be adjusted to out_put_tag then drop the out label? Right, will fix it with a new change. Thanks, Can Guo. > >> 2961 goto out; >> 2962 } >> 2963 >> 2964 init_completion(&wait); >> 2965 lrbp = &hba->lrb[tag]; >> 2966 WARN_ON(lrbp->cmd); >> 2967 err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag); >> 2968 if (unlikely(err)) >> 2969 goto out_put_tag; >> 2970 >> 2971 hba->dev_cmd.complete = &wait; >> 2972 >> 2973 ufshcd_add_query_upiu_trace(hba, UFS_QUERY_SEND, >> lrbp->ucd_req_ptr); >> 2974 /* Make sure descriptors are ready before ringing the doorbell >> */ >> 2975 wmb(); >> 2976 >> 2977 ufshcd_send_command(hba, tag); >> 2978 err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout); >> 2979 out: >> 2980 ufshcd_add_query_upiu_trace(hba, err ? UFS_QUERY_ERR : >> UFS_QUERY_COMP, >> 2981 (struct utp_upiu_req *)lrbp->ucd_rsp_ptr); >> 2982 >> 2983 out_put_tag: >> 2984 blk_put_request(req); >> 2985 out_unlock: >> 2986 up_read(&hba->clk_scaling_lock); >> 2987 return err; >> 2988 } >> 2989 >> >> --- >> 0-DAY CI Kernel Test Service, Intel Corporation >> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org > > Cheers, > Nathan
On 5/24/21 1:36 AM, Can Guo wrote: > @@ -2688,6 +2705,43 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) > + case UFSHCD_STATE_EH_SCHEDULED_FATAL: > + /* > + * pm_runtime_get_sync() is used at error handling preparation > + * stage. If a scsi cmd, e.g. the SSU cmd, is sent from hba's > + * PM ops, it can never be finished if we let SCSI layer keep > + * retrying it, which gets err handler stuck forever. Neither > + * can we let the scsi cmd pass through, because UFS is in bad > + * state, the scsi cmd may eventually time out, which will get > + * err handler blocked for too long. So, just fail the scsi cmd > + * sent from PM ops, err handler can recover PM error anyways. > + */ > + if (hba->pm_op_in_progress) { > + hba->force_reset = true; > + set_host_byte(cmd, DID_BAD_TARGET); > + cmd->scsi_done(cmd); > + goto out; > + } > + fallthrough; Hi Can, I know that this patch only moves the above code and that the above code has not been introduced by this patch. Anyway, is my understanding correct that ufshcd_err_handler() can change the host controller state from UFSHCD_STATE_EH_SCHEDULED_FATAL into UFSHCD_STATE_RESET and next into UFSHCD_STATE_OPERATIONAL? If so, if the above code completes a READ with status DID_BAD_TARGET and if recovery by the error handler succeeds, will that cause the filesystem above the UFS driver to change into read-only mode? If the above code completes a WRITE with status DID_BAD_TARGET, will that cause data corruption? Is there any other solution to prevent data corruption than merging the UFSHCD_STATE_EH_SCHEDULED_FATAL and UFSHCD_STATE_EH_SCHEDULED_NON_FATAL back into a single state and changing the ufshcd_rpm_get_sync(hba) call in ufshcd_err_handling_prepare() into a pm_runtime_get_noresume() call? Thanks, Bart.
Hi Bart, On 2021-06-17 10:49, Bart Van Assche wrote: > On 5/24/21 1:36 AM, Can Guo wrote: >> @@ -2688,6 +2705,43 @@ static int ufshcd_queuecommand(struct Scsi_Host >> *host, struct scsi_cmnd *cmd) >> + case UFSHCD_STATE_EH_SCHEDULED_FATAL: >> + /* >> + * pm_runtime_get_sync() is used at error handling preparation >> + * stage. If a scsi cmd, e.g. the SSU cmd, is sent from hba's >> + * PM ops, it can never be finished if we let SCSI layer keep >> + * retrying it, which gets err handler stuck forever. Neither >> + * can we let the scsi cmd pass through, because UFS is in bad >> + * state, the scsi cmd may eventually time out, which will get >> + * err handler blocked for too long. So, just fail the scsi cmd >> + * sent from PM ops, err handler can recover PM error anyways. >> + */ >> + if (hba->pm_op_in_progress) { >> + hba->force_reset = true; >> + set_host_byte(cmd, DID_BAD_TARGET); >> + cmd->scsi_done(cmd); >> + goto out; >> + } >> + fallthrough; > > Hi Can, > > I know that this patch only moves the above code and that the above > code > has not been introduced by this patch. Anyway, is my understanding > correct that ufshcd_err_handler() can change the host controller state > from UFSHCD_STATE_EH_SCHEDULED_FATAL into UFSHCD_STATE_RESET and next > into UFSHCD_STATE_OPERATIONAL? If so, if the above code completes a > READ > with status DID_BAD_TARGET and if recovery by the error handler > succeeds, will that cause the filesystem above the UFS driver to change > into read-only mode? If the above code completes a WRITE with status > DID_BAD_TARGET, will that cause data corruption? Is there any other > solution to prevent data corruption than merging the > UFSHCD_STATE_EH_SCHEDULED_FATAL and UFSHCD_STATE_EH_SCHEDULED_NON_FATAL > back into a single state and changing the ufshcd_rpm_get_sync(hba) call > in ufshcd_err_handling_prepare() into a pm_runtime_get_noresume() call? > Here, when hba->pm_op_in_progress is true, there cannot be READ or WRITE command since hba is resuming or suspending. When fatal erorr happens, the DID_BAD_TARGET above is intend to let the SSU (or whatever PM requests blocking suspend/resume) fail fast (neither returning HOST_BUSY nor letting the cmd pass through can achieve such purpose), so that error handling prepare won't get stuck [1] when it calls lock_system_sleep() runtime_pm_get_sync() The reason why I split UFSHCD_STATE_EH_SCHEDULED to UFSHCD_STATE_EH_SCHEDULED_FATAL and UFSHCD_STATE_EH_SCHEDULED_NON_FATAL is that 1. For non-fatal errors, HW can recover by itself, so when host state is UFSHCD_STATE_EH_SCHEDULED_NON_FATAL, cmd can still passthrough. 2. When non-fatal error (LINE-RESET for example) happens, error handler only needs to do a power mode transition without a full reset. If we only have one state, returning HOST_BUSY will get error handling prepare stuck [1], while fast failing SSU cmds shall make error handler do a full reset (which goes too far for non-fatal errors). Thanks, Can Guo. > Thanks, > > Bart.
On 5/24/21 1:36 AM, Can Guo wrote: > Current UFS IRQ handler is completely wrapped by host lock, and because > ufshcd_send_command() is also protected by host lock, when IRQ handler > fires, not only the CPU running the IRQ handler cannot send new requests, > the rest CPUs can neither. Move the host lock wrapping the IRQ handler into > specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(), > ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to further > reduce occpuation of host lock in ufshcd_transfer_req_compl(), host lock is > no longer required to call __ufshcd_transfer_req_compl(). As per test, the > optimization can bring considerable gain to random read/write performance. Hi Can, Since this patch has been applied on the AOSP kernel we see 100% reproducible lockups appearing on multiple test setups. Examples of call traces: blk_execute_rq() __scsi_execute() sd_sync_cache() sd_suspend_common() sd_suspend_system() scsi_bus_suspend() __device_suspend() blk_execute_rq() __scsi_execute() ufshcd_clear_ua_wlun() ufshcd_err_handling_unprepare() ufshcd_err_handler() process_one_work() Reverting this patch and the next patch from this series solved the lockups. Do you prefer to revert this patch or do you perhaps want us to test a potential fix? Thanks, Bart.
On 2021-06-29 06:58, Bart Van Assche wrote: > On 5/24/21 1:36 AM, Can Guo wrote: >> Current UFS IRQ handler is completely wrapped by host lock, and >> because >> ufshcd_send_command() is also protected by host lock, when IRQ handler >> fires, not only the CPU running the IRQ handler cannot send new >> requests, >> the rest CPUs can neither. Move the host lock wrapping the IRQ handler >> into >> specific branches, i.e., ufshcd_uic_cmd_compl(), >> ufshcd_check_errors(), >> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to >> further >> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host >> lock is >> no longer required to call __ufshcd_transfer_req_compl(). As per test, >> the >> optimization can bring considerable gain to random read/write >> performance. > > Hi Can, > > Since this patch has been applied on the AOSP kernel we see 100% > reproducible lockups appearing on multiple test setups. Examples of > call > traces: > > blk_execute_rq() > __scsi_execute() > sd_sync_cache() > sd_suspend_common() > sd_suspend_system() > scsi_bus_suspend() > __device_suspend() > > blk_execute_rq() > __scsi_execute() > ufshcd_clear_ua_wlun() > ufshcd_err_handling_unprepare() > ufshcd_err_handler() > process_one_work() > > Reverting this patch and the next patch from this series solved the > lockups. Do you prefer to revert this patch or do you perhaps want us > to > test a potential fix? > Hi Bart, I am waiting for more infos/logs/dumps on Buganizor to look into it. With above calltrace snippet, it is hard to figure out what is happening. Besides, we've tested this series before go upstream and we didn't see such problem. Thanks, Can Guo. > Thanks, > > Bart.
On 6/28/21 10:41 PM, Can Guo wrote: > I am waiting for more infos/logs/dumps on Buganizor to look into it. > With above calltrace snippet, it is hard to figure out what is happening. > Besides, we've tested this series before go upstream and we didn't > see such problem. Hi Can, Jaegeuk has posted a fix as you may have noticed. Thanks, Bart.
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index c4b37d2..b9b5e61 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -758,7 +758,7 @@ static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos) */ static inline void ufshcd_outstanding_req_clear(struct ufs_hba *hba, int tag) { - __clear_bit(tag, &hba->outstanding_reqs); + clear_bit(tag, &hba->outstanding_reqs); } /** @@ -1984,15 +1984,19 @@ static void ufshcd_clk_scaling_start_busy(struct ufs_hba *hba) { bool queue_resume_work = false; ktime_t curr_t = ktime_get(); + unsigned long flags; if (!ufshcd_is_clkscaling_supported(hba)) return; + spin_lock_irqsave(hba->host->host_lock, flags); if (!hba->clk_scaling.active_reqs++) queue_resume_work = true; - if (!hba->clk_scaling.is_enabled || hba->pm_op_in_progress) + if (!hba->clk_scaling.is_enabled || hba->pm_op_in_progress) { + spin_unlock_irqrestore(hba->host->host_lock, flags); return; + } if (queue_resume_work) queue_work(hba->clk_scaling.workq, @@ -2008,21 +2012,26 @@ static void ufshcd_clk_scaling_start_busy(struct ufs_hba *hba) hba->clk_scaling.busy_start_t = curr_t; hba->clk_scaling.is_busy_started = true; } + spin_unlock_irqrestore(hba->host->host_lock, flags); } static void ufshcd_clk_scaling_update_busy(struct ufs_hba *hba) { struct ufs_clk_scaling *scaling = &hba->clk_scaling; + unsigned long flags; if (!ufshcd_is_clkscaling_supported(hba)) return; + spin_lock_irqsave(hba->host->host_lock, flags); + hba->clk_scaling.active_reqs--; if (!hba->outstanding_reqs && scaling->is_busy_started) { scaling->tot_busy_t += ktime_to_us(ktime_sub(ktime_get(), scaling->busy_start_t)); scaling->busy_start_t = 0; scaling->is_busy_started = false; } + spin_unlock_irqrestore(hba->host->host_lock, flags); } static inline int ufshcd_monitor_opcode2dir(u8 opcode) @@ -2048,15 +2057,20 @@ static inline bool ufshcd_should_inform_monitor(struct ufs_hba *hba, static void ufshcd_start_monitor(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) { int dir = ufshcd_monitor_opcode2dir(*lrbp->cmd->cmnd); + unsigned long flags; + spin_lock_irqsave(hba->host->host_lock, flags); if (dir >= 0 && hba->monitor.nr_queued[dir]++ == 0) hba->monitor.busy_start_ts[dir] = ktime_get(); + spin_unlock_irqrestore(hba->host->host_lock, flags); } static void ufshcd_update_monitor(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) { int dir = ufshcd_monitor_opcode2dir(*lrbp->cmd->cmnd); + unsigned long flags; + spin_lock_irqsave(hba->host->host_lock, flags); if (dir >= 0 && hba->monitor.nr_queued[dir] > 0) { struct request *req = lrbp->cmd->request; struct ufs_hba_monitor *m = &hba->monitor; @@ -2080,6 +2094,7 @@ static void ufshcd_update_monitor(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) /* Push forward the busy start of monitor */ m->busy_start_ts[dir] = now; } + spin_unlock_irqrestore(hba->host->host_lock, flags); } /** @@ -2091,16 +2106,19 @@ static inline void ufshcd_send_command(struct ufs_hba *hba, unsigned int task_tag) { struct ufshcd_lrb *lrbp = &hba->lrb[task_tag]; + unsigned long flags; lrbp->issue_time_stamp = ktime_get(); lrbp->compl_time_stamp = ktime_set(0, 0); ufshcd_vops_setup_xfer_req(hba, task_tag, (lrbp->cmd ? true : false)); ufshcd_add_command_trace(hba, task_tag, UFS_CMD_SEND); ufshcd_clk_scaling_start_busy(hba); - __set_bit(task_tag, &hba->outstanding_reqs); if (unlikely(ufshcd_should_inform_monitor(hba, lrbp))) ufshcd_start_monitor(hba, lrbp); + spin_lock_irqsave(hba->host->host_lock, flags); + set_bit(task_tag, &hba->outstanding_reqs); ufshcd_writel(hba, 1 << task_tag, REG_UTP_TRANSFER_REQ_DOOR_BELL); + spin_unlock_irqrestore(hba->host->host_lock, flags); /* Make sure that doorbell is committed immediately */ wmb(); } @@ -2671,7 +2689,6 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) { struct ufshcd_lrb *lrbp; struct ufs_hba *hba; - unsigned long flags; int tag; int err = 0; @@ -2688,6 +2705,43 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) if (!down_read_trylock(&hba->clk_scaling_lock)) return SCSI_MLQUEUE_HOST_BUSY; + switch (hba->ufshcd_state) { + case UFSHCD_STATE_OPERATIONAL: + case UFSHCD_STATE_EH_SCHEDULED_NON_FATAL: + break; + case UFSHCD_STATE_EH_SCHEDULED_FATAL: + /* + * pm_runtime_get_sync() is used at error handling preparation + * stage. If a scsi cmd, e.g. the SSU cmd, is sent from hba's + * PM ops, it can never be finished if we let SCSI layer keep + * retrying it, which gets err handler stuck forever. Neither + * can we let the scsi cmd pass through, because UFS is in bad + * state, the scsi cmd may eventually time out, which will get + * err handler blocked for too long. So, just fail the scsi cmd + * sent from PM ops, err handler can recover PM error anyways. + */ + if (hba->pm_op_in_progress) { + hba->force_reset = true; + set_host_byte(cmd, DID_BAD_TARGET); + cmd->scsi_done(cmd); + goto out; + } + fallthrough; + case UFSHCD_STATE_RESET: + err = SCSI_MLQUEUE_HOST_BUSY; + goto out; + case UFSHCD_STATE_ERROR: + set_host_byte(cmd, DID_ERROR); + cmd->scsi_done(cmd); + goto out; + default: + dev_WARN_ONCE(hba->dev, 1, "%s: invalid state %d\n", + __func__, hba->ufshcd_state); + set_host_byte(cmd, DID_BAD_TARGET); + cmd->scsi_done(cmd); + goto out; + } + hba->req_abort_count = 0; err = ufshcd_hold(hba, true); @@ -2698,8 +2752,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) WARN_ON(ufshcd_is_clkgating_allowed(hba) && (hba->clk_gating.state != CLKS_ON)); - lrbp = &hba->lrb[tag]; - if (unlikely(lrbp->in_use)) { + if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { if (hba->pm_op_in_progress) set_host_byte(cmd, DID_BAD_TARGET); else @@ -2708,6 +2761,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) goto out; } + lrbp = &hba->lrb[tag]; WARN_ON(lrbp->cmd); lrbp->cmd = cmd; lrbp->sense_bufflen = UFS_SENSE_SIZE; @@ -2731,51 +2785,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) /* Make sure descriptors are ready before ringing the doorbell */ wmb(); - spin_lock_irqsave(hba->host->host_lock, flags); - switch (hba->ufshcd_state) { - case UFSHCD_STATE_OPERATIONAL: - case UFSHCD_STATE_EH_SCHEDULED_NON_FATAL: - break; - case UFSHCD_STATE_EH_SCHEDULED_FATAL: - /* - * pm_runtime_get_sync() is used at error handling preparation - * stage. If a scsi cmd, e.g. the SSU cmd, is sent from hba's - * PM ops, it can never be finished if we let SCSI layer keep - * retrying it, which gets err handler stuck forever. Neither - * can we let the scsi cmd pass through, because UFS is in bad - * state, the scsi cmd may eventually time out, which will get - * err handler blocked for too long. So, just fail the scsi cmd - * sent from PM ops, err handler can recover PM error anyways. - */ - if (hba->pm_op_in_progress) { - hba->force_reset = true; - set_host_byte(cmd, DID_BAD_TARGET); - goto out_compl_cmd; - } - fallthrough; - case UFSHCD_STATE_RESET: - err = SCSI_MLQUEUE_HOST_BUSY; - goto out_compl_cmd; - case UFSHCD_STATE_ERROR: - set_host_byte(cmd, DID_ERROR); - goto out_compl_cmd; - default: - dev_WARN_ONCE(hba->dev, 1, "%s: invalid state %d\n", - __func__, hba->ufshcd_state); - set_host_byte(cmd, DID_BAD_TARGET); - goto out_compl_cmd; - } ufshcd_send_command(hba, tag); - spin_unlock_irqrestore(hba->host->host_lock, flags); - goto out; - -out_compl_cmd: - scsi_dma_unmap(lrbp->cmd); - lrbp->cmd = NULL; - spin_unlock_irqrestore(hba->host->host_lock, flags); - ufshcd_release(hba); - if (!err) - cmd->scsi_done(cmd); out: up_read(&hba->clk_scaling_lock); return err; @@ -2930,7 +2940,6 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, int err; int tag; struct completion wait; - unsigned long flags; down_read(&hba->clk_scaling_lock); @@ -2947,13 +2956,13 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, tag = req->tag; WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); - init_completion(&wait); - lrbp = &hba->lrb[tag]; - if (unlikely(lrbp->in_use)) { + if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { err = -EBUSY; goto out; } + init_completion(&wait); + lrbp = &hba->lrb[tag]; WARN_ON(lrbp->cmd); err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag); if (unlikely(err)) @@ -2964,12 +2973,9 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba, ufshcd_add_query_upiu_trace(hba, UFS_QUERY_SEND, lrbp->ucd_req_ptr); /* Make sure descriptors are ready before ringing the doorbell */ wmb(); - spin_lock_irqsave(hba->host->host_lock, flags); - ufshcd_send_command(hba, tag); - spin_unlock_irqrestore(hba->host->host_lock, flags); + ufshcd_send_command(hba, tag); err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout); - out: ufshcd_add_query_upiu_trace(hba, err ? UFS_QUERY_ERR : UFS_QUERY_COMP, (struct utp_upiu_req *)lrbp->ucd_rsp_ptr); @@ -5147,6 +5153,24 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) return result; } +static bool ufshcd_is_auto_hibern8_error(struct ufs_hba *hba, + u32 intr_mask) +{ + if (!ufshcd_is_auto_hibern8_supported(hba) || + !ufshcd_is_auto_hibern8_enabled(hba)) + return false; + + if (!(intr_mask & UFSHCD_UIC_HIBERN8_MASK)) + return false; + + if (hba->active_uic_cmd && + (hba->active_uic_cmd->command == UIC_CMD_DME_HIBER_ENTER || + hba->active_uic_cmd->command == UIC_CMD_DME_HIBER_EXIT)) + return false; + + return true; +} + /** * ufshcd_uic_cmd_compl - handle completion of uic command * @hba: per adapter instance @@ -5160,6 +5184,10 @@ static irqreturn_t ufshcd_uic_cmd_compl(struct ufs_hba *hba, u32 intr_status) { irqreturn_t retval = IRQ_NONE; + spin_lock(hba->host->host_lock); + if (ufshcd_is_auto_hibern8_error(hba, intr_status)) + hba->errors |= (UFSHCD_UIC_HIBERN8_MASK & intr_status); + if ((intr_status & UIC_COMMAND_COMPL) && hba->active_uic_cmd) { hba->active_uic_cmd->argument2 |= ufshcd_get_uic_cmd_result(hba); @@ -5180,6 +5208,7 @@ static irqreturn_t ufshcd_uic_cmd_compl(struct ufs_hba *hba, u32 intr_status) if (retval == IRQ_HANDLED) ufshcd_add_uic_command_trace(hba, hba->active_uic_cmd, UFS_CMD_COMP); + spin_unlock(hba->host->host_lock); return retval; } @@ -5198,8 +5227,9 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba *hba, bool update_scaling = false; for_each_set_bit(index, &completed_reqs, hba->nutrs) { + if (!test_and_clear_bit(index, &hba->outstanding_reqs)) + continue; lrbp = &hba->lrb[index]; - lrbp->in_use = false; lrbp->compl_time_stamp = ktime_get(); cmd = lrbp->cmd; if (cmd) { @@ -5213,7 +5243,7 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba *hba, lrbp->cmd = NULL; /* Do not touch lrbp after scsi done */ cmd->scsi_done(cmd); - __ufshcd_release(hba); + ufshcd_release(hba); update_scaling = true; } else if (lrbp->command_type == UTP_CMD_TYPE_DEV_MANAGE || lrbp->command_type == UTP_CMD_TYPE_UFS_STORAGE) { @@ -5224,14 +5254,9 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba *hba, update_scaling = true; } } - if (ufshcd_is_clkscaling_supported(hba) && update_scaling) - hba->clk_scaling.active_reqs--; + if (update_scaling) + ufshcd_clk_scaling_update_busy(hba); } - - /* clear corresponding bits of completed commands */ - hba->outstanding_reqs ^= completed_reqs; - - ufshcd_clk_scaling_update_busy(hba); } /** @@ -5244,7 +5269,7 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba *hba, */ static irqreturn_t ufshcd_transfer_req_compl(struct ufs_hba *hba) { - unsigned long completed_reqs; + unsigned long completed_reqs, flags; u32 tr_doorbell; /* Resetting interrupt aggregation counters first and reading the @@ -5258,8 +5283,10 @@ static irqreturn_t ufshcd_transfer_req_compl(struct ufs_hba *hba) !(hba->quirks & UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR)) ufshcd_reset_intr_aggr(hba); + spin_lock_irqsave(hba->host->host_lock, flags); tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL); completed_reqs = tr_doorbell ^ hba->outstanding_reqs; + spin_unlock_irqrestore(hba->host->host_lock, flags); if (completed_reqs) { __ufshcd_transfer_req_compl(hba, completed_reqs); @@ -5996,13 +6023,11 @@ static void ufshcd_err_handler(struct work_struct *work) ufshcd_set_eh_in_progress(hba); spin_unlock_irqrestore(hba->host->host_lock, flags); ufshcd_err_handling_prepare(hba); + /* Complete requests that have door-bell cleared by h/w */ + ufshcd_complete_requests(hba); spin_lock_irqsave(hba->host->host_lock, flags); if (hba->ufshcd_state != UFSHCD_STATE_ERROR) hba->ufshcd_state = UFSHCD_STATE_RESET; - - /* Complete requests that have door-bell cleared by h/w */ - ufshcd_complete_requests(hba); - /* * A full reset and restore might have happened after preparation * is finished, double check whether we should stop. @@ -6085,12 +6110,11 @@ static void ufshcd_err_handler(struct work_struct *work) } lock_skip_pending_xfer_clear: - spin_lock_irqsave(hba->host->host_lock, flags); - /* Complete the requests that are cleared by s/w */ ufshcd_complete_requests(hba); - hba->silence_err_logs = false; + spin_lock_irqsave(hba->host->host_lock, flags); + hba->silence_err_logs = false; if (err_xfer || err_tm) { needs_reset = true; goto do_reset; @@ -6240,37 +6264,23 @@ static irqreturn_t ufshcd_update_uic_error(struct ufs_hba *hba) return retval; } -static bool ufshcd_is_auto_hibern8_error(struct ufs_hba *hba, - u32 intr_mask) -{ - if (!ufshcd_is_auto_hibern8_supported(hba) || - !ufshcd_is_auto_hibern8_enabled(hba)) - return false; - - if (!(intr_mask & UFSHCD_UIC_HIBERN8_MASK)) - return false; - - if (hba->active_uic_cmd && - (hba->active_uic_cmd->command == UIC_CMD_DME_HIBER_ENTER || - hba->active_uic_cmd->command == UIC_CMD_DME_HIBER_EXIT)) - return false; - - return true; -} - /** * ufshcd_check_errors - Check for errors that need s/w attention * @hba: per-adapter instance + * @intr_status: interrupt status generated by the controller * * Returns * IRQ_HANDLED - If interrupt is valid * IRQ_NONE - If invalid interrupt */ -static irqreturn_t ufshcd_check_errors(struct ufs_hba *hba) +static irqreturn_t ufshcd_check_errors(struct ufs_hba *hba, u32 intr_status) { bool queue_eh_work = false; irqreturn_t retval = IRQ_NONE; + spin_lock(hba->host->host_lock); + hba->errors |= UFSHCD_ERROR_MASK & intr_status; + if (hba->errors & INT_FATAL_ERRORS) { ufshcd_update_evt_hist(hba, UFS_EVT_FATAL_ERR, hba->errors); @@ -6325,6 +6335,9 @@ static irqreturn_t ufshcd_check_errors(struct ufs_hba *hba) * itself without s/w intervention or errors that will be * handled by the SCSI core layer. */ + hba->errors = 0; + hba->uic_error = 0; + spin_unlock(hba->host->host_lock); return retval; } @@ -6359,13 +6372,17 @@ static bool ufshcd_compl_tm(struct request *req, void *priv, bool reserved) */ static irqreturn_t ufshcd_tmc_handler(struct ufs_hba *hba) { + unsigned long flags; struct request_queue *q = hba->tmf_queue; struct ctm_info ci = { .hba = hba, - .pending = ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL), }; + spin_lock_irqsave(hba->host->host_lock, flags); + ci.pending = ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL); blk_mq_tagset_busy_iter(q->tag_set, ufshcd_compl_tm, &ci); + spin_unlock_irqrestore(hba->host->host_lock, flags); + return ci.ncpl ? IRQ_HANDLED : IRQ_NONE; } @@ -6382,17 +6399,12 @@ static irqreturn_t ufshcd_sl_intr(struct ufs_hba *hba, u32 intr_status) { irqreturn_t retval = IRQ_NONE; - hba->errors = UFSHCD_ERROR_MASK & intr_status; - - if (ufshcd_is_auto_hibern8_error(hba, intr_status)) - hba->errors |= (UFSHCD_UIC_HIBERN8_MASK & intr_status); - - if (hba->errors) - retval |= ufshcd_check_errors(hba); - if (intr_status & UFSHCD_UIC_MASK) retval |= ufshcd_uic_cmd_compl(hba, intr_status); + if (intr_status & UFSHCD_ERROR_MASK || hba->errors) + retval |= ufshcd_check_errors(hba, intr_status); + if (intr_status & UTP_TASK_REQ_COMPL) retval |= ufshcd_tmc_handler(hba); @@ -6418,7 +6430,6 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba) struct ufs_hba *hba = __hba; int retries = hba->nutrs; - spin_lock(hba->host->host_lock); intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS); hba->ufs_stats.last_intr_status = intr_status; hba->ufs_stats.last_intr_ts = ktime_get(); @@ -6449,7 +6460,6 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba) ufshcd_dump_regs(hba, 0, UFSHCI_REG_SPACE_SIZE, "host_regs: "); } - spin_unlock(hba->host->host_lock); return retval; } @@ -6626,7 +6636,6 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba, int err = 0; int tag; struct completion wait; - unsigned long flags; u8 upiu_flags; down_read(&hba->clk_scaling_lock); @@ -6639,13 +6648,13 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba, tag = req->tag; WARN_ON_ONCE(!ufshcd_valid_tag(hba, tag)); - init_completion(&wait); - lrbp = &hba->lrb[tag]; - if (unlikely(lrbp->in_use)) { + if (unlikely(test_bit(tag, &hba->outstanding_reqs))) { err = -EBUSY; goto out; } + init_completion(&wait); + lrbp = &hba->lrb[tag]; WARN_ON(lrbp->cmd); lrbp->cmd = NULL; lrbp->sense_bufflen = 0; @@ -6683,10 +6692,8 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba, /* Make sure descriptors are ready before ringing the doorbell */ wmb(); - spin_lock_irqsave(hba->host->host_lock, flags); - ufshcd_send_command(hba, tag); - spin_unlock_irqrestore(hba->host->host_lock, flags); + ufshcd_send_command(hba, tag); /* * ignore the returning value here - ufshcd_check_query_response is * bound to fail since dev_cmd.query and dev_cmd.type were left empty. @@ -6805,7 +6812,6 @@ static int ufshcd_eh_device_reset_handler(struct scsi_cmnd *cmd) u32 pos; int err; u8 resp = 0xF, lun; - unsigned long flags; host = cmd->device->host; hba = shost_priv(host); @@ -6824,11 +6830,9 @@ static int ufshcd_eh_device_reset_handler(struct scsi_cmnd *cmd) err = ufshcd_clear_cmd(hba, pos); if (err) break; + __ufshcd_transfer_req_compl(hba, pos); } } - spin_lock_irqsave(host->host_lock, flags); - ufshcd_transfer_req_compl(hba); - spin_unlock_irqrestore(host->host_lock, flags); out: hba->req_abort_count = 0; @@ -7005,20 +7009,16 @@ static int ufshcd_abort(struct scsi_cmnd *cmd) * will fail, due to spec violation, scsi err handling next step * will be to send LU reset which, again, is a spec violation. * To avoid these unnecessary/illegal steps, first we clean up - * the lrb taken by this cmd and mark the lrb as in_use, then - * queue the eh_work and bail. + * the lrb taken by this cmd and re-set it in outstanding_reqs, + * then queue the eh_work and bail. */ if (lrbp->lun == UFS_UPIU_UFS_DEVICE_WLUN) { ufshcd_update_evt_hist(hba, UFS_EVT_ABORT, lrbp->lun); + __ufshcd_transfer_req_compl(hba, (1UL << tag)); + set_bit(tag, &hba->outstanding_reqs); spin_lock_irqsave(host->host_lock, flags); - if (lrbp->cmd) { - __ufshcd_transfer_req_compl(hba, (1UL << tag)); - __set_bit(tag, &hba->outstanding_reqs); - lrbp->in_use = true; - hba->force_reset = true; - ufshcd_schedule_eh_work(hba); - } - + hba->force_reset = true; + ufshcd_schedule_eh_work(hba); spin_unlock_irqrestore(host->host_lock, flags); goto out; } @@ -7031,9 +7031,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd) if (!err) { cleanup: - spin_lock_irqsave(host->host_lock, flags); __ufshcd_transfer_req_compl(hba, (1UL << tag)); - spin_unlock_irqrestore(host->host_lock, flags); out: err = SUCCESS; } else { @@ -7063,19 +7061,15 @@ static int ufshcd_abort(struct scsi_cmnd *cmd) static int ufshcd_host_reset_and_restore(struct ufs_hba *hba) { int err; - unsigned long flags; /* * Stop the host controller and complete the requests * cleared by h/w */ ufshcd_hba_stop(hba); - - spin_lock_irqsave(hba->host->host_lock, flags); hba->silence_err_logs = true; ufshcd_complete_requests(hba); hba->silence_err_logs = false; - spin_unlock_irqrestore(hba->host->host_lock, flags); /* scale up clocks to max frequency before full reinitialization */ ufshcd_set_clk_freq(hba, true); diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index 0f0e62b..a70daf7 100644 --- a/drivers/scsi/ufs/ufshcd.h +++ b/drivers/scsi/ufs/ufshcd.h @@ -193,7 +193,6 @@ struct ufs_pm_lvl_states { * @crypto_key_slot: the key slot to use for inline crypto (-1 if none) * @data_unit_num: the data unit number for the first block for inline crypto * @req_abort_skip: skip request abort task flag - * @in_use: indicates that this lrb is still in use */ struct ufshcd_lrb { struct utp_transfer_req_desc *utr_descriptor_ptr; @@ -223,7 +222,6 @@ struct ufshcd_lrb { #endif bool req_abort_skip; - bool in_use; }; /**