[CRIU] [PATCH 4/8] x86: Add 32bit variant of TASK_SIZE

Christopher Covington cov at codeaurora.org
Fri May 15 05:43:15 PDT 2015


On 05/15/2015 07:36 AM, Pavel Emelyanov wrote:
> On 05/15/2015 02:29 PM, Cyrill Gorcunov wrote:
>> On Fri, May 15, 2015 at 02:22:22PM +0300, Pavel Emelyanov wrote:
>>>>  
>>>> -#define TASK_SIZE ((1UL << 47) - PAGE_SIZE)
>>>> +#ifdef CONFIG_X86_64
>>>> +# define TASK_SIZE	((1UL << 47) - PAGE_SIZE)
>>>> +#else
>>>> +/*
>>>> + * Task size may be limited to 3G but we need a
>>>> + * higher limit, because it's backward compatible.
>>>
>>> Can you elaborate on this, please?
>>>
>>>> + */
>>>> +# define TASK_SIZE	(0xffffe000)
>>>> +#endif
>>
>> There are two limits for user space, depending on kernel
>> configuration: 0xc0000000 or 0xffffe000. 
> 
> O_o  Really??? Which config option controls this? I remember
> the so called 4g-split patches, which extended the userspace
> memory up to amost 4G, but AFAIK they never found their way
> into the mainstream kernel.
> 
>> When the second
>> is chosen the addresses provided by mmap gonna be bigger
>> than hardcoded 3G so we should not fail in such case when
>> testing mmap results.
>>
>> Note if the kernel is configured to 3G limit the mmap
>> return address won't be higher than our TASK_SIZE, that's
>> what I meant when said "backward compatible".
> 
> This is true for any TASK_SIZE value, even if you say to be
> \infty the kernel would (should) never report addresses higher
> than some value. Why do we need it at all?

I haven't come up with good patches yet, but defining TASK_SIZE is
particularly annoying on AArch64, as there are several options. There is one
value for 32-bit processes and currently three possible values for 64-bit,
depending on how many virtual address bits are supported (current choices are
39 or 48 for 4K pages and 42 or 48 for 64K pages).

http://lxr.free-electrons.com/source/arch/arm64/include/asm/memory.h#L61
http://lxr.free-electrons.com/source/arch/arm64/Kconfig#L388

My current thought is to add an (AArch64-specific) ELF auxiliary vector for
the task size, analogous to how page size is communicated.

Alternatively, it could be probed, but I'm not currently a fan of that approach.

My recollection of debugging CRIU is that TASK_SIZE is principally used during
restore for determining where it is possible to temporarily store values when
the contents of two memory regions needs to be swapped.

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


More information about the CRIU mailing list