Am Samstag, 17. März 2007 00:50 schrieb Pete Zaitcev:
> On Fri, 16 Mar 2007 22:27:20 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > Originally, I considered freeing more memory at disconnect().
> > It turned out harder than I thought. I can add it to the port's data
> > if you like.
>
> There's no contradiction with in-struct poson and freeing it.
> It's different from an attept to lock with an in-struct lock, because
> you would have to access lock after you free. Please, take a look
> at drivers/block/ub.c.
Thence:
/*
* Downcount for deallocation. This rides on two assumptions:
* - once something is poisoned, its refcount cannot grow
* - opens cannot happen at this time (del_gendisk was done)
* If the above is true, we can drop the lock, which we need for
* blk_cleanup_queue(): the silly thing may attempt to sleep.
* [Actually, it never needs to sleep for us, but it calls might_sleep()]
*/
The second assumption made there is not true for USB serial.
destroy_serial:
/* the ports are cleaned up and released in port_release() */
for (i = 0; i < serial->num_ports; ++i)
if (serial->port[i]->dev.parent != NULL) {
device_unregister(&serial->port[i]->dev);
serial->port[i] = NULL;
}
Device unregistration is done too late to do what ub does. Arguably
for now we don't free usbserial's memory immediately, so for now
the flag could be moved into the structure, but I don't like doing what
then should be reversed.
Regards
Oliver
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
