[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] VMX status report. Xen:26323 & Dom0:3.7.1



On 10/01/13 08:57, Jan Beulich wrote:
>>>> On 10.01.13 at 08:51, "Ren, Yongjie" <yongjie.ren@xxxxxxxxx> wrote:
>> New issue(1)
>> ==============
>> 1. sometimes live migration failed and reported call trace in dom0
>>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1841 
> 
> For the failed allocation, the only obvious candidate appears to be
> 
>       err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
> 
> which quite obviously can be of (almost) arbitrary size because
> 
>       nr_pages = m.num;
>       if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>               return -EINVAL;
> 
> really only checks for completely insane values.
> 
> This got introduced by Andres' "xen/privcmd: add PRIVCMD_MMAPBATCH_V2
> ioctl" and is becoming worse with Mukesh's recent "xen: privcmd:
> support autotranslated physmap guests", which added another
> similar (twice as large) allocation in alloc_empty_pages().
> 
> I'd like to note that the forward ported kernels don't appear to
> have a similar issue, as they never allocates more than a page at
> a time. Was that code consulted at all when that addition was
> done?

I did highlight this at the time[1].

See [2] for how I avoided this allocation.

David

[1] http://lists.xen.org/archives/html/xen-devel/2012-08/msg02208.html
[2] http://lists.xen.org/archives/html/xen-devel/2012-08/msg02092.html

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.