On Fri, Dec 9, 2011 at 09:35, Oliver Neukum <oneukum@xxxxxxx> wrote:
> Am Freitag, 9. Dezember 2011, 02:15:17 schrieb Thilo-Alexander Ginkel:
>> 555 static void acm_tty_hangup(struct tty_struct *tty)
>> 556 {
>> 557 »···struct acm *acm = tty->driver_data;
>> 558 »···tty_port_hangup(&acm->port);
>> 559 »···mutex_lock(&open_mutex);
>> 560 »···acm_port_down(acm);
>> 561 »···mutex_unlock(&open_mutex);
>> 562 }
>>
>> Another idea that came to my mind: If data transmission is in progress
>> when the suspend happens (as indicated by acm->transmitting), what are
>> the effects of returning EBUSY (just in case the suspend is an auto
>> suspend - under which circumstances do these happen?)? May this cause
>> trouble on resume?
>
> Returning -EBUSY will make the driver core again wait an autosuspend period
> and then retry the autosuspend.
Ok, so we can hopefully rule this out s a source of any problems.
Is there any chance of acm_probe and acm_tty_hangup running
concurrently on resume? That's one combination where I see the
possibility of port and / or its lock being in an temporarily
inconsistent state, which is not guarded by another lock.
Is spin_lock_init(&port->lock) atomic on x86_64?
Regards,
Thilo
--
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
