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

[Santosh Jodh <Santosh.Jodh@xxxxxxxxxx>]

I only cared about linux_gnttab_grant_map for user mode blkback. You told me to 
change all others while I was in there.

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
Sent: Tuesday, April 17, 2012 12:56 AM
To: Ian Campbell; AP
Cc: Santosh Jodh; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] alloca() in linux_privcmd_map_foreign_bulk causing 
segfault

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