Skip to content
Snippets Groups Projects
  1. Jul 06, 2023
  2. Jun 16, 2023
  3. Jun 01, 2023
  4. May 31, 2023
  5. May 17, 2023
  6. Apr 12, 2023
  7. Apr 03, 2023
  8. Feb 21, 2023
    • Adrien Thierry's avatar
      scsi: ufs: core: Initialize devfreq synchronously · 7dafc3e0
      Adrien Thierry authored
      During UFS initialization, devfreq initialization is asynchronous:
      ufshcd_async_scan() calls ufshcd_add_lus(), which in turn initializes
      devfreq for UFS. The simple ondemand governor is then loaded. If it is
      built as a module, request_module() is called and throws a warning:
      
        WARNING: CPU: 7 PID: 167 at kernel/kmod.c:136 __request_module+0x1e0/0x460
        Modules linked in: crct10dif_ce llcc_qcom phy_qcom_qmp_usb ufs_qcom phy_qcom_snps_femto_v2 ufshcd_pltfrm phy_qcom_qmp_combo ufshcd_core phy_qcom_qmp_ufs qcom_wdt socinfo fuse ipv6
        CPU: 7 PID: 167 Comm: kworker/u16:3 Not tainted 6.2.0-rc6-00009-g58706f7fb045 #1
        Hardware name: Qualcomm SA8540P Ride (DT)
        Workqueue: events_unbound async_run_entry_fn
        pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        pc : __request_module+0x1e0/0x460
        lr : __request_module+0x1d8/0x460
        sp : ffff800009323b90
        x29: ffff800009323b90 x28: 0000000000000000 x27: 0000000000000000
        x26: ffff800009323d50 x25: ffff7b9045f57810 x24: ffff7b9045f57830
        x23: ffffdc5a83e426e8 x22: ffffdc5ae80a9818 x21: 0000000000000001
        x20: ffffdc5ae7502f98 x19: ffff7b9045f57800 x18: ffffffffffffffff
        x17: 312f716572667665 x16: 642f7366752e3030 x15: 0000000000000000
        x14: 000000000000021c x13: 0000000000005400 x12: ffff7b9042ed7614
        x11: ffff7b9042ed7600 x10: 00000000636c0890 x9 : 0000000000000038
        x8 : ffff7b9045f2c880 x7 : ffff7b9045f57c68 x6 : 0000000000000080
        x5 : 0000000000000000 x4 : 8000000000000000 x3 : 0000000000000000
        x2 : 0000000000000000 x1 : ffffdc5ae5d382f0 x0 : 0000000000000001
        Call trace:
         __request_module+0x1e0/0x460
         try_then_request_governor+0x7c/0x100
         devfreq_add_device+0x4b0/0x5fc
         ufshcd_async_scan+0x1d4/0x310 [ufshcd_core]
         async_run_entry_fn+0x34/0xe0
         process_one_work+0x1d0/0x320
         worker_thread+0x14c/0x444
         kthread+0x10c/0x110
         ret_from_fork+0x10/0x20
      
      This occurs because synchronous module loading from async is not
      allowed. According to __request_module():
      
        /*
         * We don't allow synchronous module loading from async.  Module
         * init may invoke async_synchronize_full() which will end up
         * waiting for this task which already is waiting for the module
         * loading to complete, leading to a deadlock.
         */
      
      Such a deadlock was experienced on the Qualcomm QDrive3/sa8540p-ride. With
      DEVFREQ_GOV_SIMPLE_ONDEMAND=m, the boot hangs after the warning.
      
      Fix both the warning and the deadlock by moving devfreq initialization out
      of the async routine.
      
      Tested on the sa8540p-ride by using fio to put the UFS under load, and
      printing the trace generated by
      /sys/kernel/tracing/events/ufs/ufshcd_clk_scaling events. The trace looks
      similar with and without the change.
      
      Link: https://lore.kernel.org/r/20230217194423.42553-1-athierry@redhat.com
      
      
      Signed-off-by: default avatarAdrien Thierry <athierry@redhat.com>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      7dafc3e0
  9. Feb 08, 2023
  10. Jan 24, 2023
  11. Jan 19, 2023
    • Johan Hovold's avatar
      scsi: ufs: core: Fix devfreq deadlocks · ba810437
      Johan Hovold authored
      
      There is a lock inversion and rwsem read-lock recursion in the devfreq
      target callback which can lead to deadlocks.
      
      Specifically, ufshcd_devfreq_scale() already holds a clk_scaling_lock
      read lock when toggling the write booster, which involves taking the
      dev_cmd mutex before taking another clk_scaling_lock read lock.
      
      This can lead to a deadlock if another thread:
      
        1) tries to acquire the dev_cmd and clk_scaling locks in the correct
           order, or
      
        2) takes a clk_scaling write lock before the attempt to take the
           clk_scaling read lock a second time.
      
      Fix this by dropping the clk_scaling_lock before toggling the write booster
      as was done before commit 0e9d4ca4 ("scsi: ufs: Protect some contexts
      from unexpected clock scaling").
      
      While the devfreq callbacks are already serialised, add a second
      serialising mutex to handle the unlikely case where a callback triggered
      through the devfreq sysfs interface is racing with a request to disable
      clock scaling through the UFS controller 'clkscale_enable' sysfs
      attribute. This could otherwise lead to the write booster being left
      disabled after having disabled clock scaling.
      
      Also take the new mutex in ufshcd_clk_scaling_allow() to make sure that any
      pending write booster update has completed on return.
      
      Note that this currently only affects Qualcomm platforms since commit
      87bd0501 ("scsi: ufs: core: Allow host driver to disable wb toggling
      during clock scaling").
      
      The lock inversion (i.e. 1 above) was reported by lockdep as:
      
       ======================================================
       WARNING: possible circular locking dependency detected
       6.1.0-next-20221216 #211 Not tainted
       ------------------------------------------------------
       kworker/u16:2/71 is trying to acquire lock:
       ffff076280ba98a0 (&hba->dev_cmd.lock){+.+.}-{3:3}, at: ufshcd_query_flag+0x50/0x1c0
      
       but task is already holding lock:
       ffff076280ba9cf0 (&hba->clk_scaling_lock){++++}-{3:3}, at: ufshcd_devfreq_scale+0x2b8/0x380
      
       which lock already depends on the new lock.
      [  +0.011606]
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&hba->clk_scaling_lock){++++}-{3:3}:
              lock_acquire+0x68/0x90
              down_read+0x58/0x80
              ufshcd_exec_dev_cmd+0x70/0x2c0
              ufshcd_verify_dev_init+0x68/0x170
              ufshcd_probe_hba+0x398/0x1180
              ufshcd_async_scan+0x30/0x320
              async_run_entry_fn+0x34/0x150
              process_one_work+0x288/0x6c0
              worker_thread+0x74/0x450
              kthread+0x118/0x120
              ret_from_fork+0x10/0x20
      
       -> #0 (&hba->dev_cmd.lock){+.+.}-{3:3}:
              __lock_acquire+0x12a0/0x2240
              lock_acquire.part.0+0xcc/0x220
              lock_acquire+0x68/0x90
              __mutex_lock+0x98/0x430
              mutex_lock_nested+0x2c/0x40
              ufshcd_query_flag+0x50/0x1c0
              ufshcd_query_flag_retry+0x64/0x100
              ufshcd_wb_toggle+0x5c/0x120
              ufshcd_devfreq_scale+0x2c4/0x380
              ufshcd_devfreq_target+0xf4/0x230
              devfreq_set_target+0x84/0x2f0
              devfreq_update_target+0xc4/0xf0
              devfreq_monitor+0x38/0x1f0
              process_one_work+0x288/0x6c0
              worker_thread+0x74/0x450
              kthread+0x118/0x120
              ret_from_fork+0x10/0x20
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
              CPU0                    CPU1
              ----                    ----
         lock(&hba->clk_scaling_lock);
                                      lock(&hba->dev_cmd.lock);
                                      lock(&hba->clk_scaling_lock);
         lock(&hba->dev_cmd.lock);
      
        *** DEADLOCK ***
      
      Fixes: 0e9d4ca4 ("scsi: ufs: Protect some contexts from unexpected clock scaling")
      Cc: stable@vger.kernel.org      # 5.12
      Cc: Can Guo <quic_cang@quicinc.com>
      Tested-by: default avatarAndrew Halaney <ahalaney@redhat.com>
      Signed-off-by: default avatarJohan Hovold <johan+linaro@kernel.org>
      Reviewed-by: default avatarBart Van Assche <bvanassche@acm.org>
      Link: https://lore.kernel.org/r/20230116161201.16923-1-johan+linaro@kernel.org
      
      
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ba810437
  12. Jan 18, 2023
  13. Jan 14, 2023
  14. Jan 12, 2023
  15. Dec 30, 2022
  16. Nov 08, 2022
Loading