Re: [RFC][-rc9 PATCH] Bluetooth: fix oops in rfcomm

["Dave Young" <hidave.darkstar@gmail.com>]

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))?