Messages in this thread | | | Date | Sun, 24 Jan 2021 08:38:13 +0000 | From | Paul Cercueil <> | Subject | Re: [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
| |