On 10/01/2014 05:07 PM, Andrew Morton wrote: > On Mon, 29 Sep 2014 21:47:14 -0400 Sasha Levin <sasha.levin@xxxxxxxxxx> wrote: > >> Currently we're seeing a few issues which are unexplainable by looking at the >> data we see and are most likely caused by a memory corruption caused >> elsewhere. >> >> This is wasting time for folks who are trying to figure out an issue provided >> a stack trace that can't really point out the real issue. >> >> This patch introduces poisoning on struct page, vm_area_struct, and mm_struct, >> and places checks in busy paths to catch corruption early. >> >> This series was tested, and it detects corruption in vm_area_struct. Right now >> I'm working on figuring out the source of the corruption, (which is a long >> standing bug) using KASan, but the current code is useful as it is. > > Is this still useful if/when kasan is in place? Yes, the corruption we're seeing happens inside the struct rather than around it. kasan doesn't look there. When kasan is merged, we could complement this patchset by making kasan trap on when the poison is getting written, rather than triggering a BUG in some place else after we saw the corruption. > It looks fairly cheap - I wonder if it should simply fall under > CONFIG_DEBUG_VM rather than the new CONFIG_DEBUG_VM_POISON. Config options are cheap as well :) I'd rather expand it further and add poison/kasan trapping into other places such as the vma interval tree rather than having to keep it "cheap". Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>