Messages in this thread | | | Subject | Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory | From | Konstantin Khlebnikov <> | Date | Wed, 11 Oct 2017 10:00:06 +0300 |
| |
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.
| |