Hi Vegard, > This is a resend of a patch I sent earlier. It fixes a reproducible > oops (see http://lkml.org/lkml/2008/7/13/89 for test case), and I'd > be very happy for some feedback from Bluetooth people. Can this be > included for testing somewhere? I don't have any bluetooth devices > myself, so all my testing is limited to creating/releasing devices > with ioctl (I'm not sure that's good enough). > > Dave: I have extended the rfcomm_dev_lock to include all the setup and > teardown of a single device. On second thought, it doesn't really make > sense to use a separate lock for that. May I have your opinion on this > second version? (I've fixed the comments/BUG_ON that you pointed out.) it seems it is the actually the first time, I see this one. Anyway, so holding that lock is a bad idea. Fixing this the right way might be tricky since the TTY layer is involved here and own the kobject. So I would say we have to make sure that the RFCOMM TTY will hangup when calling RELEASEDEV or otherwise fail. Regards Marcel -- 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
