On Tue, 2019-05-07 at 08:23 +0000, David Laight wrote: > From: Jonathan Cameron > > Sent: 05 May 2019 16:44 > > On Fri, 3 May 2019 15:58:38 +0000 > > Philippe Schenker <philippe.schenker@xxxxxxxxxxx> wrote: > > > > > On Fri, 2019-05-03 at 14:39 +0000, David Laight wrote: > > > > From: Philippe Schenker > > > > > Sent: 03 May 2019 14:57 > > > > > In some cases, the wait_completion got interrupted. This caused the > > > > > error-handling to mutex_unlock the function. The before turned on > > > > > interrupt then got called anyway. In the ISR then completion() > > > > > was called causing problems. > > > > > > > > > > Making this wait_completion non interruptible solves the problem. > > > > > > > > Won't the same thing happen if the interrupt occurs just after > > > > the timeout? > > > > > > > > David > > > > > > > > > > > > - > > > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > > > > MK1 1PT, > > > > UK > > > > Registration No: 1397386 (Wales) > > > > > > > > > > You're of course right... Thanks for pointing this out. I will send a v2 > > > with a > > > better solution then. > > > > > > > Isn't the timeout long enough that it should only happen if the hardware has > > a fault? If that's the case, I wouldn't worry too much about possibility of > > an interrupt causing confusion as long as it isn't catastrophic. > > The 'confusion' is likely to be 'catastrophic' unless the code is written > to handle it properly. > > Cancelling callbacks is hard to get right and often not done properly. > Timing out an interrupt is much the same problem. > > David I sorted it out now, there where also some more bugs I found and corrected. @Jonathan: I will send a completely new series of patches that will include patch 3/3 from this series but not the one you already applied. This due to increased patch number and different order... > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, > UK > Registration No: 1397386 (Wales) >
