Re: [PATCH v3] usb: dwc3: debugfs: Prevent any register access when devices is runtime suspended

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Greg, Oliver,

On 3/16/23 5:06 PM, Oliver Neukum wrote:


On 16.03.23 12:17, Greg Kroah-Hartman wrote:
On Thu, Mar 16, 2023 at 12:28:58PM +0530, Udipto Goswami wrote:
When the dwc3 device is runtime suspended, various required clocks would
get disabled and it is not guaranteed that access to any registers would
work. Depending on the SoC glue, a register read could be as benign as
returning 0 or be fatal enough to hang the system.

In order to prevent such scenarios of fatal errors, bail out of debugfs
function is dwc3 is suspended.

Signed-off-by: Udipto Goswami <quic_ugoswami@xxxxxxxxxxx>
---
v3: Replace pr_err to dev_err.

  drivers/usb/dwc3/debugfs.c | 60 ++++++++++++++++++++++++++++++++++++++
  1 file changed, 60 insertions(+)

diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 850df0e6bcab..4a9d0994f3b4 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -544,6 +544,12 @@ static int dwc3_link_state_show(struct seq_file *s, void *unused)
      u32            reg;
      u8            speed;
+    if (pm_runtime_suspended(dwc->dev)) {
+        dev_err(dwc->dev,
+            "Invalid operation, DWC3 suspended!");
+        return -EINVAL;
+    }

What prevents the device from being suspened right after you check this?

I agree if the debugfs is access while suspend is in progress and lets say the pm suspended status got reflected after the check. In this case we will still run into the same fatal error scenario. But this will be very tight race if in my understanding.

Our scenario was very simple, plug out the cable and try accessing the debugfs. In this scenario at least the kernel should not crash.


Indeed. If you really need a semantics of not waking up the device if
somebody reads through debugfs, the attached patch should do the job.
But do you really need it?

Well, the intention was just to avoid the kernel crash. I believe in any case the kernel should handle it gracefully and bail out. I understand this patch won't help in the race condition which Greg pointed out though.

Could you please suggest any other way which we can try out ?

     Regards
         Oliver



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux