linux-kernel - Re: [PATCH] usb: dwc3: Potential fix of possible dwc3 interrupt storm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240907003946.qn6t3xw65qwl2cn7@synopsys.com>
Date: Sat, 7 Sep 2024 00:39:53 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Selvarasu Ganesan <selvarasu.g@...sung.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jh0801.jung@...sung.com" <jh0801.jung@...sung.com>,
        "dh10.jung@...sung.com" <dh10.jung@...sung.com>,
        "naushad@...sung.com" <naushad@...sung.com>,
        "akash.m5@...sung.com" <akash.m5@...sung.com>,
        "rc93.raju@...sung.com" <rc93.raju@...sung.com>,
        "taehyun.cho@...sung.com" <taehyun.cho@...sung.com>,
        "hongpooh.kim@...sung.com" <hongpooh.kim@...sung.com>,
        "eomji.oh@...sung.com" <eomji.oh@...sung.com>,
        "shijie.cai@...sung.com" <shijie.cai@...sung.com>
Subject: Re: [PATCH] usb: dwc3: Potential fix of possible dwc3 interrupt storm

On Sat, Sep 07, 2024, Selvarasu Ganesan wrote:
> 
> Hi Thinh,
> 
> I ran the code you recommended on our testing environment and was able 
> to reproduce the issue one time.
> 
> When evt->flags contains DWC3_EVENT_PENDING, I've included the following 
> debugging information: I added this debug message at the start of 
> dwc3_event_buffers_cleanup and dwc3_event_buffers_setup functions in 
> during suspend and resume.
> 
> The results were quite interesting . I'm curious to understand how 
> evt->flags is set to DWC3_EVENT_PENDING, and along with DWC3_GEVNTSIZ is 
> equal to 0x1000 during the suspend.

That is indeed strange.

> Its means that the previous bottom-half handler prior to suspend might 
> still be executing in the middle of the process.
> 
> Could you please give your suggestions here? And let me know if anything 
> want to test or additional details are required.
> 
> 
> ##DBG: dwc3_event_buffers_cleanup:
>   evt->length    :0x1000
>   evt->lpos      :0x20c
>   evt->count     :0x0
>   evt->flags     :0x1 // This is Unexpected if DWC3_GEVNTSIZ(0)(0xc408): 
> 0x00001000. Its means that previous bottom-half handler may be still 
> running in middle

Perhaps.

But I doubt that's the case since it shouldn't take that long for the
bottom-half to be completed before the next resume yet the flag is still
set.

> 
>   DWC3_GEVNTSIZ(0)(0xc408)       : 0x00001000
>   DWC3_GEVNTCOUNT(0)(0xc40c)     : 0x00000000
>   DWC3_DCFG(0xc700)              : 0x00e008a8
>   DWC3_DCTL(0xc704)              : 0x0cf00a00
>   DWC3_DEVTEN(0xc708)            : 0x00000000
>   DWC3_DSTS(0xc70c)              : 0x00d20cd1
> 

The controller status is halted. So there's no problem with
soft-disconnect. For the interrupt mask in GEVNTSIZ to be cleared,
that likely means that the bottom-half had probably completed.

> 
> ##DBG: dwc3_event_buffers_setup:
>   evt->length    :0x1000
>   evt->lpos      :0x20c

They fact that evt->lpos did not get updated tells me that there's
something wrong with memory access to your platform during suspend and
resume.

>   evt->count     :0x0
>   evt->flags     :0x1 // Still It's not clearing in during resume.
> 
>   DWC3_GEVNTSIZ(0)(0xc408)       : 0x00000000
>   DWC3_GEVNTCOUNT(0)(0xc40c)     : 0x00000000
>   DWC3_DCFG(0xc700)              : 0x00080800
>   DWC3_DCTL(0xc704)              : 0x00f00000
>   DWC3_DEVTEN(0xc708)            : 0x00000000
>   DWC3_DSTS(0xc70c)              : 0x00d20001
> 

Please help look into your platform to see what condition triggers this
memory access issue. If this is a hardware quirk, we can properly update
the change and note it to be so.

Thanks,
Thinh

(If possible, for future tests, please dump the dwc3 tracepoints. Many
thanks for the tests.)