Messages in this thread | | | Date | Tue, 19 Dec 2006 11:21:38 -0800 (PST) | From | J <> | Subject | Possible race condition in usb-serial.c |
| |
Hi, I read usb-serial.c code (in 2.6.19) and I cannot figure out how it is supposed to prevent race condition and premature deletion of usb_serial structure. I see that the code attempts to protect usb_serial by ref counting, but it does not appear to be correct. I am not 100% sure in my findings, so I will appreciate if somebody will double check.
Suppose: A:->usb_serial_disconnect A: -> usb_serial_put (serial); A: -> kref_put A: if ((atomic_read(&kref->refcount) == 1) Suppose refcount is 1 A: -> release -> destroy_serial
B: -> serial_open B: -> usb_serial_get_by_index B: serial = serial_table[index] B: -> kref_get(&serial->kref);
A: -> return_serial(serial); A: serial_table[serial->minor + i] = NULL; A: -> kfree (serial);
B: continue to use serial, which was already freed.
So, I am missing something or the USB serial driver is broken?
As I understand it, the correct use of ref counted pointers it to increment ref count of an object for each outstanding pointer to this object. But usb-serial.c keeps one or more pointers to usb_serial in serial_table, and does not increments the counter for any of them!
Thank you John
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |