On Thu, Jul 18, 2013 at 08:45:43AM -0400, Peter Hurley wrote: > On 07/17/2013 02:10 PM, Peter Hurley wrote: > >That said, preventing rfcomm_dev destruction by holding the dlc lock > >is poor design (not that I'm suggesting you should be required to fix it though) > >and something that at least needs documenting. > > > >Regarding acquiring a snapshot of dev->id is fine, provided that the id > >cannot be reallocated in between dropping the dlc lock and subsequently > >scanning the rfcomm_dev_list for that id. > > Or at least a FIXME comment that the id could potentially be reallocated > between dropping the dlc lock and the subsequent rfcomm_dev_get(). > > Regards, > Peter Hurley I must admit I don't know how to solve the issue you outlined. I cannot also understand why that code exists in first place: why should we release the device when RFCOMM_RELEASE_ONHUP is set but we didn't get a HUP? Gianluca -- 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
