lkml.org 
[lkml]   [2020]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] usb: musb: Fix runtime PM race in musb_queue_resume_work
Hi,

Le lun. 17 août 2020 à 13:59, Tony Lindgren <tony@atomide.com> a
écrit :
> * Paul Cercueil <paul@crapouillou.net> [200809 12:54]:
>> 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).
>>
>> 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.
>
> Yes we should use is_runtime_suspended, thanks for fixing it.
> Things still work for me so:
>
> Reviewed-by: Tony Lindgren <tony@atomide.com>
> Tested-by: Tony Lindgren <tony@atomide.com>

Bin, can you take this patch?

Thanks,
-Paul


\
 
 \ /
  Last update: 2020-09-28 02:53    [W:0.069 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site