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]

Date:   Thu, 05 Jan 2017 13:19:39 +0200
From:   Felipe Balbi <balbi@...nel.org>
To:     Baolin Wang <baolin.wang@...aro.org>
Cc:     Janusz Dziedzic <janusz.dziedzic@...il.com>,
        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,

Baolin Wang <baolin.wang@...aro.org> writes:

[...]

>>>> and you have triggered this with mailine? How? We don't write to GEVNT*
>>>> registers from PM code and we only allow runtime_suspend with cable
>>>> dettached.
>>>
>>> Sorry for late reply since I am busy on other things. I just agreed
>>> with the possible races pointed by Janusz. I need to look at if these
>>> are happened on my platform and also I found some out of tree code
>>> which will clean the GEVNTCOUNT register when stop the gadget. I will
>>> check the mainline kernel and resend new patch if I make this problem
>>> clearly. Anyway thanks for your help and suggestion.
>>
>> IOW, you sent me a patch to be integrated in the tree which everybody in
>> the whole world uses and you didn't even test anything in that very
>> tree? How am I supposed to trust you're sending me tested patches from
>> now on?
>>
>> Clearly you have no empathy for those working countless hours to keep
>> this stable and working. If you're ready to send me a completely
>> untested patch and claim that it's fixing a race condition you have
>> never seen for yourself, it becomes difficult to trust any patches
>> you're sending me.
>
> I am sure I send you every patch was tested on my vendor platform and
> I saw the problem on my platform. But like my said I missed something
> that we have masked all interrupts in the dwc3 interrupt handler, so
> the real reason maybe caused by some out of tree code on my vendor
> platform which will clean the GEVNTCOUNT register when stop the
> gadget. Moreover I did not only do this one thing, and some other

and this is the very problem I'm referring to. If you have changes on
DWC3 on your "vendor tree" you're testing *mainline* DWC3. Which kernel
is your tree even based on? 

> problem I also need time to test and investigate. So I think I need
> some time to make things clear, then I can send you one better patch
> with the correct explanation, am I wrong here?

you're wrong to assume your vendor tree *with changes on DWC3 driver* is
equivalent to testing *mainline*. That just doesn't add up.

If you were adding just platform init code (something under your mach-*
directory, some DTS, etc) that's fine. But you have changes on the USB
peripheral controller driver. This makes me rather uneasy about your
patches. I mean, if you have changes to DWC3, what other changes do you
have there? Also, if your changes are in PM code, which we have support
in upstream, this suggests that you're using older kernel from the time
when we didn't have PM support upstream. This means you're using
something pre-v4.8. Which kernel are you using?

cheers

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)