Hi, On 12/21/2016 11:18 PM, OGAWA Hirofumi wrote: > Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> writes: > >>> We set CMD_RING_STATE_ABORTED state under locking. I'm not checking what >>> is for taking lock for register though, I guess it should be enough just >>> lock around of read=>write of ->cmd_ring if need lock. >> After your patch it should be enough to have the lock only while >> reading and writing the cmd_ring register. >> >> If we want a locking fix that applies more easily to older stable >> releases before your change then the lock needs to cover set >> CMD_RING_STATE_ABORT, read cmd_reg, write cmd_reg and busiloop >> checking CRR bit. Otherwise the stop cmd ring interrupt handler may >> restart the ring just before we start checing CRR. The stop cmd ring >> interrupt will set the CMD_RING_STATE_ABORTED to >> CMD_RING_STATE_RUNNING so ring will really restart in the interrupt >> handler. > Just for record (no chance to make patch I myself for now, sorry), while > checking locking slightly, I noticed unrelated missing locking. > > xhci_cleanup_command_queue() > > We are calling it without locking, but we need to lock for accessing list. Yeah. I can make the patch. Best regards, Lu Baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
