On Thu, Apr 25, 2024 at 10:37:21AM -0700, RD Babiera wrote: > On Thu, Apr 25, 2024 at 2:49 AM Heikki Krogerus > <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > > I'm probable missing something, but wouldn't it be safer to check > > port->state after grabbing the lock? > > I could have been more explicit in describing the deadlock, my bad. > But there are two > threads here: > > Thread A starts in the TCPM. It is the port state machine that > transitions to DR_SWAP > and holds port->lock. When it unregisters DisplayPort Alt Mode, it goes into the > DP Alt Mode driver and hangs until any DP Alt Mode work is finished. > > Thread B starts in the DP Alt Mode driver. It attempts to call tcpm_enter_mode > and the call to mutex_lock in tcpm_queue_vdm_unlock hangs because Thread A > holds the lock. Thread A will never drop the lock because it waits for Thread B > to finish. > > So, the check is done before grabbing the lock because the thread needs to avoid > grabbing the lock in the first place. If port->state changes between > queueing and > sending the message, the VDM state machine will drop the message anyways > because port->state isn't in the ready state as well. Okay, thanks for the explanation. Reviewed-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> -- heikki
