On Sat, Aug 28, 2021 at 01:36:56PM +0200, Fabio M. De Francesco wrote: > Remove _enter_critical_mutex() and _exit_critical_mutex(). They are > unnecessary wrappers, respectively to mutex_lock_interruptible() and > to mutex_unlock(). They also have an odd interface that takes an unused > argument named pirqL of type unsigned long. > The original code enters the critical section if the mutex API is > interrupted while waiting to acquire the lock; therefore it could lead > to a race condition. Use mutex_lock() because it is uninterruptible and > so avoid that above-mentioned potential race condition. > > Tested-by: Pavel Skripkin <paskripkin@xxxxxxxxx> > Reviewed-by: Pavel Skripkin <paskripkin@xxxxxxxxx> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@xxxxxxxxx> > --- > > v5: Fix a typo in the subject line. Reported by Aakash Hemadri. > > v4: Tested and reviewed by Pavel Skripkin. No changes to the code. > > v3: Assume that the original authors don't expect that > mutex_lock_interruptible() can be really interrupted and then lead to > a potential race condition. Furthermore, Greg Kroah-Hartman makes me > notice that "[] one almost never needs interruptable locks in a driver". > Therefore, replace the calls to mutex_lock_interruptible() with calls to > mutex_lock() since the latter is uninterruptible and avoid race > conditions without the necessity to handle -EINTR errors. Based on a recent conversation on the linux-usb mailing list, perhaps I was wrong: https://lore.kernel.org/r/20210829015825.GA297712@xxxxxxxxxxxxxxxxxxx Can you check what happens with your change when you disconnect the device and these code paths are being called? That is when you do want the lock interrupted. Yes, the logic still seems wrong, but I don't want to see the code now just lock up entirely with this change as it is a change in how things work from today. thanks, greg k-h
