From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: 정재훈 <jh0801.jung@samsung.com>,
"Thinh Nguyen" <Thinh.Nguyen@synopsys.com>,
"'Felipe Balbi'" <balbi@kernel.org>,
"'Greg Kroah-Hartman'" <gregkh@linuxfoundation.org>
Cc: "'open list:USB XHCI DRIVER'" <linux-usb@vger.kernel.org>,
'open list' <linux-kernel@vger.kernel.org>,
'Seungchull Suh' <sc.suh@samsung.com>,
'Daehwan Jung' <dh10.jung@samsung.com>,
"cpgs@samsung.com" <cpgs@samsung.com>,
"cpgsproxy5@samsung.com" <cpgsproxy5@samsung.com>
Subject: Re: [PATCH] usb: dwc3: Add dwc3 lock for blocking interrupt storming
Date: Fri, 11 Mar 2022 03:51:03 +0000 [thread overview]
Message-ID: <0ae388d8-0809-f09a-55a8-b682c9dc42c5@synopsys.com> (raw)
In-Reply-To: <017f01d834f1$bc3a9c30$34afd490$@samsung.com>
정재훈 wrote:
>> -----Original Message-----
>> From: Thinh Nguyen [mailto:Thinh.Nguyen@synopsys.com]
>> Sent: Friday, March 11, 2022 10:57 AM
>> To: 정재훈; Thinh Nguyen; 'Felipe Balbi'; 'Greg Kroah-Hartman'
>> Cc: 'open list:USB XHCI DRIVER'; 'open list'; 'Seungchull Suh'; 'Daehwan
>> Jung'; cpgs@samsung.com; cpgsproxy5@samsung.com
>> Subject: Re: [PATCH] usb: dwc3: Add dwc3 lock for blocking interrupt
>> storming
>>
>> 정재훈 wrote:
>>> Hi.
>>>
>>>> -----Original Message-----
>>>> From: Thinh Nguyen [mailto:Thinh.Nguyen@synopsys.com]
>>>> Sent: Thursday, March 10, 2022 11:14 AM
>>>> To: JaeHun Jung; Felipe Balbi; Greg Kroah-Hartman
>>>> Cc: open list:USB XHCI DRIVER; open list; Seungchull Suh; Daehwan
>>>> Jung
>>>> Subject: Re: [PATCH] usb: dwc3: Add dwc3 lock for blocking interrupt
>>>> storming
>>>>
>>>> Hi,
>>>>
>>>> JaeHun Jung wrote:
>>>>> Interrupt Storming occurred with a very low probability of occurrence.
>>>>> The occurrence of the problem is estimated to be caused by a race
>>>>> condition between the top half and bottom half of the interrupt
>>>>> service
>>>> routine.
>>>>> It was confirmed that variables have values that cannot be held when
>>>>> ISR occurs through normal H / W irq.
>>>>> ====================================================================
>>>>> = (struct dwc3_event_buffer *) ev_buf = 0xFFFFFF88DE6A0380 (
>>>>> (void *) buf = 0xFFFFFFC01594E000,
>>>>> (void *) cache = 0xFFFFFF88DDC14080,
>>>>> (unsigned int) length = 4096,
>>>>> (unsigned int) lpos = 0,
>>>>> (unsigned int) count = 0, <<
>>>>> (unsigned int) flags = 1, <<
>>>>> ====================================================================
>>>>> = "evt->count=0" and "evt->flags=DWC3_EVENT_PENDING" cannot be set
>>>>> at the same time.
>>>>>
>>>>> We estimate that a race condition occurred between dwc3_interrupt()
>>>>> and dwc3_process_event_buf() called by
>>>>> dwc3_gadget_process_pending_events().
>>>>> So I try to block the race condition through spin_lock.
>>>>
>>>> This looks like it needs a memory barrier. Would this work for you?
>>> Maybe it could be. But "evt->count = 0;" is updated on
>> dwc3_process_event_buf().
>>> So, I think spin_lock is more clear routine for this issue.
>>>
>>
>> Not really. If problem is due to the evt->flags not updated in time, then
>> the solution should be using the memory barrier. The spin_lock would
>> obfuscate the issue. And we should avoid using spin_lock in the top-half.
>
> This issue was occurred by watchdog. The interrupt occurred in units of 4 to 5us and cannot be released until the bottom is executed.
> If it is a problem with the memory barrier, the value should be updated after a few clocks and the TOP should run normally. Isn't it?
Can you guarantee that a value is stored after X amount of time, every time?
> And Could you explain me why we should avoid using spin_lock in the top-half.
>
The top-half and bottom-half are serialized. While the bottom-half
handler is running, the interrupt should be masked. If the top-half got
called in the middle of the bottom-half handler, something else is
wrong. There should not be a race that requires a spin_lock for this
particular critical section.
The problem you're seeing is pointing toward a memory barrier issue.
Also you noted that there's an "interrupt storm", which doesn't indicate
to me that it's due to PCIe legacy interrupt de-assertion delay response
either.
Can you test it out and we can take a look further?
BR,
Thinh
next prev parent reply other threads:[~2022-03-11 3:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220307052605epcas2p2b84f6db2642863ed61373070f508e200@epcas2p2.samsung.com>
2022-03-07 5:24 ` [PATCH] usb: dwc3: Add dwc3 lock for blocking interrupt storming JaeHun Jung
2022-03-10 2:13 ` Thinh Nguyen
2022-03-11 1:29 ` 정재훈
2022-03-11 1:56 ` Thinh Nguyen
2022-03-11 2:43 ` 정재훈
2022-03-11 3:51 ` Thinh Nguyen [this message]
2022-03-11 3:55 ` Thinh Nguyen
2022-03-11 5:01 ` 정재훈
2022-03-14 23:18 ` Thinh Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ae388d8-0809-f09a-55a8-b682c9dc42c5@synopsys.com \
--to=thinh.nguyen@synopsys.com \
--cc=balbi@kernel.org \
--cc=cpgs@samsung.com \
--cc=cpgsproxy5@samsung.com \
--cc=dh10.jung@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=jh0801.jung@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sc.suh@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).