> > Thanks for the report. Did this show up as a real bug? What's your > use case? Or is it a theoretic concern raised when doing code review? I assume it was code review, right? > Yeah the hwpoison_filter_flags_* values are not referenced strictly > safe to concurrent updates. I didn't care it because the typical usage > is for hwpoison test tools to _first_ echo hwpoison_filter_flags_* > values into the debugfs and _then_ start injecting hwpoison errors. > Otherwise you cannot get reliable test results. The updated value is > guaranteed to be visible because there are file mutex UNLOCK and page > LOCK operations in between. Sorry that's not true -- all the x86 memory ordering constraints only apply to a single CPU or same address. But I agree it doesn't really matter for a debugging feature like this. So unless there's a very simple fix I would be inclined to leave it alone, perhaps with a comment added. Comments? -Andi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>