On Fri, Dec 21, 2012 at 5:09 PM, Andy Lutomirski <[email protected]> wrote: > On Fri, Dec 21, 2012 at 4:59 PM, Michel Lespinasse <[email protected]> wrote: >> On Fri, Dec 21, 2012 at 4:36 PM, Andy Lutomirski <[email protected]> wrote: >>> Something's buggy here. My evil test case is stuck with lots of >>> threads spinning at 100% system time. >>> >>> The tasks in question use MCL_FUTURE but not MAP_POPULATE. These >>> tasks are immune to SIGKILL. >> >> Looking into it. >> >> There seems to be a problem with mlockall - the following program >> fails in an unkillable way even before my changes: >> >> #include <sys/mman.h> >> #include <stdio.h> >> #include <stdint.h> >> >> int main(void) { >> void *p = mmap(NULL, 0x100000000000, >> PROT_READ | PROT_WRITE, >> MAP_PRIVATE | MAP_ANON | MAP_NORESERVE, >> -1, 0); >> printf("p: %p\n", p); >> mlockall(MCL_CURRENT); >> return 0; >> } >> >> I think my changes propagate this existing problem so it now shows up >> in more places :/
So in my test case, the issue was caused by the mapping being 2^32 pages, which overflowed the integer 'nr_pages' argument to __get_user_pages, which caused an infinite loop as __get_user_pages() would return 0 so __mm_populate() would make no progress. When dropping one zero from that humongous size in the test case, the test case becomes at least killable. > Hmm. I'm using MCL_FUTURE with MAP_NORESERVE, but those mappings are > not insanely large. Should MAP_NORESERVE would negate MCL_FUTURE? > I'm doing MAP_NORESERVE, PROT_NONE to prevent pages from being > allocated in the future -- I have no intention of ever using them. MAP_NORESERVE doesn't prevent page allocation, but PROT_NONE does (precisely because people use it the same way as you do :) > The other odd thing I do is use MAP_FIXED to replace MAP_NORESERVE pages. Yes, I've seen people do that here too. Could you share your test case so I can try reproducing the issue you're seeing ? Thanks, -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
