On Mon, Feb 06, 2012 at 11:23:18PM +0100, Andi Kleen wrote: > On Mon, Feb 06, 2012 at 03:57:52AM -0500, Trevor Kramer wrote: > > I have a program which can use libnuma to allocate memory using > > numa_alloc_onnode() or using malloc. When running in malloc mode > > everything works fine but when running under libnuma mode I get > > consistent kernel panics with the following traces. This only occurs > > when multiple threads are running. Has anyone seen this before or have > > any recommendations on how to debug further? > > > Looks like a THP problem. > > For RHEL issues you normally need to talk to RedHat, these lists > are more for mainline. Well at this point we don't know yet if this affects mainline too or not. To be sure, you can file a bugzilla.redhat.com and we'll fix it ASAP and submit the fix upstream if it happens there too. Best of all is if you can send the source of the program that trigger this attached to the bugzilla (or by email). Or create a small source testcase that can reproduce it. A BUG_ON is triggering, probably the rmap mapcount vs page->mapcount one. I'm unsure why this is related to libnuma only, and a wild guess could be that the vma policy does something wrong over the vmas to the point rmap won't find the pmds (like wrong vma splitting or something). But thanks to the BUG_ON there is close to zero risk of data or memory corruption, just an annoyance we need to fix (plus the program I assume requires root to use libnuma). The last time (more than one year ago) I've seen this it was a bug in the vma splitting. So again guessing wild, it could be a missing vma_adjust_trans_huge in mempolicy.c or some other place splitting vmas to create a partial vma policy on an existing vma. Thanks, Andrea -- To unsubscribe from this list: send the line "unsubscribe linux-numa" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
