Re: [PATCH] Fix overflow in vma length when copying mmap on clone

From: Siddhesh Poyarekar
Date: Tue Apr 24 2012 - 15:47:39 EST


On 25 April 2012 01:10, Siddhesh Poyarekar <siddhesh.poyarekar@xxxxxxxxx> wrote:
> That was supposed to be errno, not the pointer. I had added my own
> syscall wrappers to eliminate glibc and then reverted it to the
> original smaller-to-read reproducer and this got left behind in the
> process. The demo program is supposed to show "successed" for
> iterations 16383 to 16390 since the overflow happens at 16TB. All
> iterations before it (and after) show a fork failure.
>
> /proc/sys/vm/overcommit_memory is 0.
>
> Perhaps a cleaner demo program would have been:

Ugh, I missed some details once again. The demo below will show
"Unexpected success" without this patch in place. The system I've
tested this patch on is an x86_64 F-16 box with 4GB RAM and 6GB swap.

> #include <stdio.h>
> #include <unistd.h>
> #include <sys/mman.h>
> #include <errno.h>
>
> #define GIG 1024 * 1024 * 1024L
> #define EXTENT 16393
>
> int main(void)
> {
>        int i, r;
>        void *m;
>        char buf[1024];
>        int prev_failed = 0;
>
>        for (i = 0; i < EXTENT; i++) {
>                m = mmap(NULL, (size_t) 1 * 1024 * 1024 * 1024L,
>                         PROT_READ | PROT_WRITE, MAP_PRIVATE |
> MAP_ANONYMOUS, 0, 0);
>
>                if (m == (void *)-1) {
>                        printf("MMAP Failed: %d\n", errno);
>                        return 1;
>                }
>
>                r = fork();
>
>                if (r == 0) {
>                        return 0;
>                } else if (r < 0) {
>                        prev_failed = 1;
>                        /* Fork failed as expected */
>                }
>                else if (r > 0 && prev_failed) {
>                        printf("Unexpected success at %d\n", i);
>                        wait(NULL);
>                        return 1;
>                }
>        }
>        return 0;
> }
>



--
Siddhesh Poyarekar
http://siddhesh.in
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/