Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing segfault

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-04-17 at 05:57 +0100, AP wrote:
> On xen-unstable 25164:5bbda657a016, when I try to map in large amounts
> of pages (in the GB range) from a guest in to Dom0

Out of interest -- what are you doing this for?

>  using
> xc_map_foreign_bulk() I am hitting a segfault.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>     err=0x7ffff67f4010, num=<optimized out>)
>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> 52      return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #0  0x00007ffff7bd38d5 in linux_privcmd_map_foreign_bulk (xch=0x605050,
>     h=<optimized out>, dom=2, prot=<optimized out>, arr=0x7ffff6bf5010,
>     err=0x7ffff67f4010, num=<optimized out>)
>     at /usr/include/x86_64-linux-gnu/bits/string3.h:52
> #1  0x00007ffff7bd1ffc in xc_map_foreign_bulk (xch=<optimized out>,
>     dom=<optimized out>, prot=<optimized out>, arr=<optimized out>,
>     err=<optimized out>, num=<optimized out>) at xc_foreign_memory.c:79
> 
> This was working for me with Xen 4.1.2. On comparing
> linux_privcmd_map_foreign_bulk() between 4.1.2 and unstable I see that
> the pfn array in linux_privcmd_map_foreign_bulk() is being allocated
> using alloca() in unstable vs malloc() in 4.1.2. So I am blowing the
> stack with the call.

I bet this is due to Linux's stack guard page. This means that if you
try and increase the stack by more than ~1 page you skip entirely over
the "next" stack page and into the guard.

Does it help if after the alloca you add a loop which touches the first
word of each page of the new buffer? Since the stack grows down you
might actually need to do it backwards from the end of the array in
order to start at the end which is nearest the existing stack? (it's
before coffee o'clock so thinking about stack direction isn't my strong
point yet...)

The switch to alloca was made recently in order to optimise the hotpath
for a userspace I/O backend.

BTW, Santosh, it didn't occur to me at the time but what is privcmd mmap
doing on the hot path for the userspace I/O anyway? Most hotpath
operations should really be grant table ops, a backend shouldn't be
relying on the privileges accorded to dom0 -- for one thing it should be
expected to work in a driver domain.

>  If I replace the alloca() with malloc() the call
> goes through. What is the way around this? Should I be using
> xc_map_foreign_batch() instead, which I think is deprecated? Please
> advice...
> 
> Thanks,
> AP
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel