On Wed, 26 Feb 2014, Dan Williams wrote: > When CPU2 takes the lock it will certainly be after hubA->disconnected > has been set, but I don't see what prevents de-referencing the hubA > pointer from crashing. Continuing the above example: > > CPU1 CPU2 > mutex_lock(peer_lock) > unlink_peers(portA, portC) > mutex_unlock(peer_lock) > mutex_lock(peer_lock) > device_unregister(portA) > hubA = to_usb_hub(portA) > kref_put(hubA) > free(hubA) > if (!hubA->disconnected) /* crash */ > link_peers(portB, portA) > mutex_unlock(peer_lock) > > I think this needs to be solved by portB not being able to lookup portA > in the first place. Which I believe is addressed by wider synchronizing > usb_hub_create_port_device() vs setting hub->disconnected (as you > mention below). Right. The routines that follow the hub and port pointers will need to be very careful about this. Each step is subject to a race: going from port to hdev = port->child, to hub = usb_hub_to_struct_hub(hdev), to port = hub->ports[port1 - 1]. Alan Stern -- 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
