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

[AP <apxeng@xxxxxxxxx>]

On Tue, Apr 17, 2012 at 12:27 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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?

Mainly to speedup gva to gpa translation. I map in most of guest
memory and do the page table walk within my app as I find doing the
translation using libxc to be quite slow.

>>  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