An error occurred fetching the project authors.
  1. 11 Jul, 2024 1 commit
  2. 05 Jun, 2024 1 commit
  3. 31 May, 2024 4 commits
  4. 12 Apr, 2024 2 commits
  5. 10 Mar, 2024 1 commit
  6. 24 Jan, 2024 2 commits
  7. 19 Dec, 2023 1 commit
  8. 14 Dec, 2023 2 commits
  9. 25 Nov, 2023 1 commit
  10. 17 Oct, 2023 2 commits
  11. 27 Sep, 2023 1 commit
  12. 08 Aug, 2023 1 commit
  13. 31 Jul, 2023 3 commits
  14. 23 Jul, 2023 1 commit
  15. 11 Jul, 2023 1 commit
  16. 16 Jun, 2023 3 commits
  17. 01 Jun, 2023 3 commits
  18. 31 May, 2023 1 commit
  19. 17 May, 2023 1 commit
  20. 12 Apr, 2023 1 commit
  21. 03 Apr, 2023 2 commits
  22. 21 Feb, 2023 1 commit
    • 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-g58706f7f #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.comSigned-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
  23. 08 Feb, 2023 1 commit
  24. 24 Jan, 2023 1 commit
  25. 19 Jan, 2023 1 commit
    • 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.orgSigned-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ba810437
  26. 14 Jan, 2023 1 commit