Ok. I've added the smatch mailing list. And I'm top posting because I am a bad person. It would be better if I could look at an existing patch for one of these things. regards, dan carpenter On Wed, Jan 22, 2014 at 01:28:29PM -0500, Joe Lawrence wrote: > Hi Dan, > > (Feel free to CC the smatch list if you think it's appropriate.) > > Part of the work we do at Stratus is hardening various device drivers > for our HW platform against surprise PCI hotplug removal. Even though > it has been documented in Linux Device Drivers for years, we still see > GregKH occasionally explaining to folks that on surprise hotplug, PCI > drivers "will suddenly start reading all 0xff and will then need to > abort whatever it was doing." > > For example, the code provided in section 14.7.1. Dynamic Devices of > LDD: > > result = readl(ptr); > if (result = = ~(u32)0) /* card removed */ > return -ENODEV; > > Currently we manually inspect code drops for unsafe reads of PCI > space. We have essentially two cases of PCI reads: > > Case 1 - Read data doesn't matter - driver reads from the device, then > writes something back. Although the device has gone missing, we > usually consider this as benign as writing to missing HW has no effect. > > Case 2 - Read data affects control flow or kernel/driver data - driver > reads data and then bases execution on the result, or read data is > copied into a kernel/driver data structure. Typically we check these > reads and if necessary, twiddle enough state to get the driver into its > error handler. > > Currently we manually inspect new code drops for potentially > hotplug-unsafe reads. I was wondering if you thought it would be worth > adding a check in smatch, even as an optional flag. There is probably > already an existing pattern that we could mimic to add this. As I > don't hack on the smatch code itself, I was wondering if you could > point that out. (I can go off and try implementing / testing.) > > A means of automating this code audit would be helpful to us here at > Stratus and perhaps the kernel community in general. > > Thanks for any suggestions, > > -- Joe -- To unsubscribe from this list: send the line "unsubscribe smatch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
