On Fri, Aug 09, 2019 at 01:03:05PM +0200, Wolfram Sang wrote: > Hi all, > > Krzysztof Adamski kindly made me aware of a race condition that most > 'unreg_slave' callbacks have. Quote: > > "BTW, I have added this synchronize_irq() in unreg_slave callback just to > make sure it is save to set idev->slave to NULL already. Most of the > controllers do not have such a guard and I'm wondering why that wouldn't > be a problem for them. Like the i2c-rcar.c - isn't there a small race > condition if some slave interrupt triggers just before ICSIER is cleared > and somehow does not finish before priv->slave is set to NULL? This is > the situation I was afraid of and tried to solve by using this > synchronize_irq()." > > I have fixed the rcar and emev2 drivers now. From a glimpse, the at91, > designware, iproc, and stm32f7 are likely affected, too. Please check if > that is the case and if you also need 'synchronize_irq' or spinlocks to > protect the pointer to the slave. Let's hope I managed to get all > relevat people to CC. I'm wondering if synchronize_irq() is enough. The free_irq() theoretically is the best option, though I dunno which one suits in which cases better. -- With Best Regards, Andy Shevchenko
