Messages in this thread | | | Date | Tue, 21 Sep 2010 10:12:23 +0200 | Subject | Re: Problem with debugfs | From | "Andi Kleen" <> |
| |
> > 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
| |