On 26/03/13 15:43, Matthew Garrett wrote: > I'm not quite clear what you mean. We have a fairly solid idea as to > what the underlying problem here is, and I don't think this makes any > more assumptions than the existing code does. Right, it doesn't make more assumptions, but the assumptions that the existing code makes is causing problems, hence the need for your updated patch. I'm fully expecting that the updated patch will also cause us problems/require additional patches. I really don't want to keep patching/tweaking this all the way to -rc6 and beyond. Have you tested this patch against one of those machines that suffers from the original bricking problem? Ben, does this patch fix your issue? I dug my buggy-as-hell ASUS machine out from under my desk and it suffers from the max_size == 0 problem which this patch doesn't fix, but that's already been discussed. > I'm kind of reluctant, because the cost of getting this wrong is > hardware damage. Right now we believe that we're resistant to hardware > damage but have introduced another problem in the process. If we can > find a way to satisfy both constraints then I think that that's > worthwhile. I'm concerned we're going to end up introducing more constraints because some other class of platforms doesn't work with this patch. It expects DataSize and storage_size to correlate meaningfully, and I'm not at all convinced that will be true everywhere, even though it's not an unreasonable expectation. Maybe we should leave the existing checks in place and create a whitelist for those machines that absolutely must be able to write to the variable store, e.g. to initiate garbage collection, or where QueryVariableInfo() is known to be inaccurate, or where we know we can have the full use of pstore without bricking the machine. Yes, we'll have to maintain the whitelist and we'll no doubt get bug reports for machines that need to be added to the list, but at least no one is going to brick their laptops, and the fix is simply adding an ID to the list, not reimplementing our workarounds with the risk of breaking X number of machines that were previously working just fine. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html