[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