| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 21 Sep 2010 10:12:23 +0200 From: "Andi Kleen" <andi@...stfloor.org> To: "Wu Fengguang" <fengguang.wu@...el.com> Cc: "Andi Kleen" <andi@...stfloor.org>, "KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com>, "Kenneth" <liguozhu@...wei.com>, greg@...ah.com, linux-kernel@...r.kernel.org, "Naoya Horiguchi" <n-horiguchi@...jp.nec.com>, "linux-mm" <linux-mm@...ck.org> Subject: Re: Problem with debugfs > > 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists