Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory

[Konstantin Khlebnikov <khlebnikov@yandex-team.ru>]

On 11.10.2017 01:25, Andrew Morton wrote:
> On Fri, 06 Oct 2017 14:32:34 +0300 Konstantin Khlebnikov <khlebnikov@yandex-team.ru> wrote:
> 
>> If start_code / end_code pointers are screwed then "VmExe" could be bigger
>> than total executable virtual memory and "VmLib" becomes negative:
>>
>> VmExe:	  294320 kB
>> VmLib:	18446744073709327564 kB
>>
>> VmExe and VmLib documented as text segment and shared library code size.
>>
>> Now their sum will be always equal to mm->exec_vm which sums size of
>> executable and not writable and not stack areas.
> 
> When does this happen?  What causes start_code/end_code to get "screwed"?

I don't know exactly what happened.
I've seen this for huge (>2Gb) statically linked binary which has whole world inside.

For it start_code .. end_code range also covers one of rodata sections.
Probably this is bug in customized linker, elf loader or both.

Anyway CONFIG_CHECKPOINT_RESTORE allows to change these pointers,
thus we cannot trust them without validation.

> 
> When these pointers are screwed, the result of end_code-start_code can
> still be wrong while not necessarily being negative, yes?  In which
> case we'll still display incorrect output?
> 

Here we split exec_vm into main code segment and libraries.

Range start_code .. end_code declared as main code segment.
In my case it's bigger than exec_vm, so libraries have to be negative.

After my patch libraries will be 0 and whole exec_vm show as VmExe.
At least sum VmExe + VmLib stays correct and both of them sane.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>