Re: [RE-RESEND PATCH 1/4] usb: musb: Fix runtime PM race in musb_queue_resume_work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sergei,


Le sam. 23 janv. 2021 à 19:41, Sergei Shtylyov <sergei.shtylyov@xxxxxxxxx> 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@xxxxxxxxxxxxxxx # v4.9+
 Signed-off-by: Paul Cercueil <paul@xxxxxxxxxxxxxxx>
 Reviewed-by: Tony Lindgren <tony@xxxxxxxxxxx>
 Tested-by: Tony Lindgren <tony@xxxxxxxxxxx>
[...]


MBR, Sergei





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux