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: <20240904010322.leqt3pap6lguivg4@synopsys.com>
Date: Wed, 4 Sep 2024 01:03:26 +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 Mon, Sep 02, 2024, Selvarasu Ganesan wrote:
> 
> I would like to reconfirm from our end that in our failure scenario, we 
> observe that DWC3_EVENT_PENDING is set in evt->flags when the dwc3 
> resume sequence is executed, and the dwc->pending_events flag is not 
> being set.
> 

If the controller is stopped, no event is generated until it's restarted
again. (ie, you should not see GEVNTCOUNT updated after clearing
DCTL.run_stop). If there's no event, no interrupt assertion should come
from the controller.

If the pending_events is not set and you still see this failure, then
likely that the controller had started, and the interrupt is generated
from the controller event. This occurs along with the interrupt
generated from your connection notification from your setup.

Check your platform and internal team, what condition would cause the
setup to generate the interrupt and what condition would stop this
custom connection interrupt assertion? This is outside of what's defined
by the flow of the controller.

BR,
Thinh