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

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

On Jan 11, 2013, at 3:34 AM, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>>>> On 10.01.13 at 18:10, Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx> wrote:
>> On Jan 10, 2013, at 3:57 AM, "Jan Beulich" <JBeulich@xxxxxxxx> 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().
>> 
>> Perhaps the err_array in this case, since alloc_empty_pages only happens for 
>> auto translated dom0s.
>> 
>> Not familiar wether libxl changes (or is even capable of changing) 
>> parameters of the migration code. But right now in libxc, mapping is done in 
>> MAX_BATCH_SIZE batches, which are of size 1024. So we are talking about 1024 
>> ints, which is *one* page.
>> 
>> So is really the kernel incapable of allocating one measly page?
>> 
>> This leads me to think that it might be gather_array, but that one would 
>> allocate a grand total of two pages.
> 
> The log indicated a failed order-4 allocation though. So maybe not
> that allocation after all (be the basically unbounded size here is a
> problem in any case).

Unless somehow the batch size got changed to 16384, this most definitely is not 
err_array. Would be good to ascertain that.

I do see how gather array avoids allocations larger than O(0). Let me look into 
cooking a similar solution for err_array.

Andres
> 
>> In any case, both functions allocate arbitrary number of pages, and that is 
>> the fundamental problem.
>> 
>> What is the approach in the forward ported kernel wrt to gather_array?
> 
> There's no gather_array there. It simply sets up things one page
> at a time. (And you can always go and check linux-2.6.18-xen.hg).
> 
> Jan
> 


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