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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.04.12 at 09:27, 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?
> 
>>  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...)

This should really be done by the alloca() implementation itself -
anything else is a bug.

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

Probably this should be made size-dependent ...

> 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 this indeed turns out to be a hot path for something at all?

Jan

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




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