Am Dienstag, den 15.08.2017, 16:38 +0300 schrieb Anton Volkov: > On 15.08.2017 16:20, Oliver Neukum wrote: > > > > Am Dienstag, den 15.08.2017, 15:59 +0300 schrieb Anton Volkov: > > > > > > Hello. > > > > > > While searching for races in the Linux kernel I've come across > > > "drivers/usb/misc/adutux.ko" module. Here is a question that I came up > > > with while analyzing results. Lines are given using the info from Linux > > > v4.12. > > > > > > Consider the following case: > > > > > > Thread 1: Thread 2: > > > adu_release > > > ->adu_release_internal adu_disconnect > > > <READ &dev->udev->dev> dev->udev = NULL > > > (adutux.c: line 298) (adutux.c: line 771) > > > usb_deregister_dev > > > > > > Comments in the source code point at the possibility of adu_release() > > > being called separately from adu_disconnect(). adu_release() and > > > adu_disconnect() acquire different mutexes, so they are not protected > > > from one another. If adu_disconnect() changes dev->udev before its value > > > is read in adu_release_internal() there will be a NULL pointer > > > dereference on a read attempt. Is this case feasible from your point of > > > view? > > > > > > Thank you for your time. > > > > Hi, > > > > your analysis seems correct to me. In fact it looks like > > > > 66d4bc30d128e7c7ac4cf64aa78cb76e971cec5b > > USB: adutux: remove custom debug macro > > > > more or less broke disconnect on this driver > > (the URBs can also finish after dev->udev = NULL) > > > > Do you want to do a fix or do you want me to do it? > > > > Regards > > Oliver > > > > Hello, Oliver. > > I am not sure about the best way to solve this problem. If you have any > ideas about it then it would probably be better if you could handle the > fix. Or if you share the ideas I can prepare a patch. Hi, given the age of the drivers I would suggest to simply remove the debugging statements Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
