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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-04-17 at 16:19 +0100, Santosh Jodh wrote:
> I only cared about linux_gnttab_grant_map for user mode blkback. You
> told me to change all others while I was in there.

Oh, right, I remember now.

Given that reverting it for this case will still leave the same issue
for the grant case (which I'd forgotten about) I suppose the appropriate
workaround is to touch the alloca'd memory in the appropriate order in
all cases (perhaps with an alloca helper macro).

Ian.

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