Messages in this thread | | | Date | Mon, 14 Jul 2008 15:06:33 +0800 | From | "Dave Young" <> | Subject | Re: [RFC][-rc9 PATCH] Bluetooth: fix oops in rfcomm |
| |
On Mon, Jul 14, 2008 at 2:23 PM, Vegard Nossum <vegard.nossum@gmail.com> wrote: > On Mon, Jul 14, 2008 at 4:41 AM, Dave Young <hidave.darkstar@gmail.com> wrote: >>> This patch attempts to correct this by only removing the device from the >>> internal rfcomm list of devices at the final unregister, so that the id >>> won't get reused until the device has been completely destructed. >> >> It looks good, I agree with your change. > > Thanks for looking! > >> if (IS_ERR(dev->tty_dev)) { >> err = PTR_ERR(dev->tty_dev); >> list_del(&dev->list); >> kfree(dev); >> return err; >> } >> >> The list_del need to be protected as well. > > After looking at the code once again I wonder if we should not extend > the protection even a bit further. Just below, we have this: > > if (device_create_file(dev->tty_dev, &dev_attr_address) < 0) > > ..which means that we could theoretically get here, be preempted by > another process which 1. releases the device id, and 2. recreates the > same device id. When we resume execution of the first task, > device_create_file() would be called for a file that already exists. > > Should the rfcomm_dev_lock be extended to include protecting these > things as well? It seems somehow wrong, but I am not sure how it > should be done correctly either.
I think they need some locking indeed, but I guess rfcomm_dev_lock is not the one for it.
Another problem, please see the following code:
/* Refcount should only hit zero when called from rfcomm_dev_del() which will have taken us off the list. Everything else are refcounting bugs. */ BUG_ON(!list_empty(&dev->list));
Maybe replace it with BUG_ON(!test_bit(RFCOMM_TTY_RELEASED, &dev->flags))?
| |