Messages in this thread | | | Date | Mon, 28 Sep 2020 02:52:35 +0200 | From | Paul Cercueil <> | Subject | Re: [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
| |