lkml.org 
[lkml]   [2006]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPossible 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/

\
 
 \ /
  Last update: 2006-12-19 20:31    [W:0.049 / U:1.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site