Hi all,
I noticed recently that my "size-512" slab cache is constantly growing
on a machine with a lot of Bluetooth activity. kmemleak points to struct
hci_conn allocation in hci_conn_add().
After examining the code I found out that, on a successful connection
attempt, the connection is registered with sysfs and that sysfs code is
responsible for freeing struct hci_conn once sysfs device is released.
However, on an unsuccessful connection attempt (connection complete
event returns with a non-zero status in hci_conn_complete_evt()), the
connection is never registered with sysfs in the first place, so it
never gets unregistered and struct hci_conn is subsequently leaked.
This leak can be reliably reproduced by trying to page a dummy BDADDR,
e.g. with something like
while true
do
hcitool cc 11:22:33:44:55:66
done
and watching the "size-512" slab cache grow.
I instrumented the code with printk's to confirm that del_conn() is
never queued and executed in this case. I tested this on 2.6.31.5 and
2.6.31.6, on arm and x86 with same results.
IMHO, there are two problems here:
First, conn->devref counting is wrong, it is initialized to zero and
only incremented once a successful connection complete event arrives.
But any hci_conn_del() will decrement it, (whether from a failed
connection complete event or maybe for some other reason) - in this case
below 0, so del_conn() never gets queued for execution.
Second, del_conn() never calls put_device(&conn->dev) if the connection
has not been actually added to the sysfs tree - which, in this case, it
isn't.
I've created a simple patch that fixes these problems, which follows.
Cheers,
Aleksandar
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
