linux-kernel - Re: [PATCH] usb: dwc3: gadget: Avoid race between dwc3 interrupt handler and irq thread handler

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: <CAMz4kuJEdBxcZPRrv7-YV7jpZFtajY9j9G24iWDmiMp-t0+fAw@mail.gmail.com>
Date:   Tue, 27 Dec 2016 10:58:22 +0800
From:   Baolin Wang <baolin.wang@...aro.org>
To:     Lu Baolu <baolu.lu@...ux.intel.com>
Cc:     Felipe Balbi <balbi@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        USB <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH] usb: dwc3: gadget: Avoid race between dwc3 interrupt
 handler and irq thread handler

Hi,

On 27 December 2016 at 10:39, Lu Baolu <baolu.lu@...ux.intel.com> wrote:
> Hi,
>
> On 12/26/2016 04:01 PM, Baolin Wang wrote:
>> On some platfroms(like x86 platform), when one core is running the USB gadget
>> irq thread handler by dwc3_thread_interrupt(), meanwhile another core also can
>> respond other interrupts from dwc3 controller and modify the event buffer by
>> dwc3_interrupt() function, that will cause getting the wrong event count in
>> irq thread handler to make the USB function abnormal.
>>
>> We should add spin_lock/unlock() in dwc3_check_event_buf() to avoid this race.
>
> Why not spin_lock_irq ones? This lock seems to be used in both
> normal and interrupt threads. Or, I missed anything?

I assumed there are no nested interrupts, when one core is running at
interrupt context, then it can not respond any other interrupts, which
means we don't need to disable local IRQ now, right?

-- 
Baolin.wang
Best Regards