lkml.org 
[lkml]   [2021]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RE-RESEND PATCH 1/4] usb: musb: Fix runtime PM race in musb_queue_resume_work
Hi Sergei,


Le sam. 23 janv. 2021 à 19:41, Sergei Shtylyov
<sergei.shtylyov@gmail.com> a écrit :
> On 1/23/21 5:24 PM, Paul Cercueil wrote:
>
>> musb_queue_resume_work() would call the provided callback if the
>> runtime
>> PM status was 'active'. Otherwise, it would enqueue the request if
>> the
>> hardware was still suspended (musb->is_runtime_suspended is true).
>>
>> This causes a race with the runtime PM handlers, as it is possible
>> to be
>> in the case where the runtime PM status is not yet 'active', but the
>> hardware has been awaken (PM resume function has been called).
>
> Awakened. :-)

Oops. Hopefully Bin or Greg can fix it when merging (if I don't need to
v2, that is to say - feedback welcome).

Cheers,
-Paul

>> When hitting the race, the resume work was not enqueued, which
>> probably
>> triggered other bugs further down the stack. For instance, a telnet
>> connection on Ingenic SoCs would result in a 50/50 chance of a
>> segmentation fault somewhere in the musb code.
>>
>> Rework the code so that either we call the callback directly if
>> (musb->is_runtime_suspended == 0), or enqueue the query otherwise.
>>
>> Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from
>> invalid context for hdrc glue")
>> Cc: stable@vger.kernel.org # v4.9+
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> Reviewed-by: Tony Lindgren <tony@atomide.com>
>> Tested-by: Tony Lindgren <tony@atomide.com>
> [...]
>
>
> MBR, Sergei


\
 
 \ /
  Last update: 2021-01-24 10:01    [W:0.836 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site