On 2017-06-29 00:20, David Thomson wrote: > On 2017-06-19 18:34, Peter Rosin wrote: >> It would certainly be nice to know why .owner is clobbered, because I >> don't see it. But then again, I don't know what sources I should be >> reading... > Hi Peter > > Thanks for your reply. Unfortunately we cannot reproduce the issue on a newer kernel as it requires userspace applications (for processing the hotswap) that rely on our (many) changes to the kernel. I appreciate you taking the time to consider the issue. Still interested in what base version you have and if there are any patches of relevance to the i2c subsystem... The oldest mainline that had i2c_del_mux_adapter is v4.6 (May 2016), so I had a second look at that. Could you also tell us what i2c-mux driver this is and whether it is expected that .owner is NULL in the first place? In other words, is the i2c-mux driver in question built-in or a loaded module? If you have not added any new i2c-mux driver (which I doubt, you would surely have mentioned that) the only way that this race can happen is if the driver is removed twice since i2c_del_mux_adapter is only called in .remove (and in .probe on failure, but I don't think that can race). At least that's the case for the i2c-mux drivers that I looked at... It seems pretty serious that a driver can have its .remove called twice so I suspect your patch just papers over a much bigger problem? So, why is the i2c-mux driver being removed more than once? The module refcounting must be badly screwed up for that to happen. Or? Cheers, Peter
