All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] proc: do not show VmExe bigger than total executable virtual memory
@ 2017-10-06 11:32 ` Konstantin Khlebnikov
  0 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2017-10-06 11:32 UTC (permalink / raw)
  To: linux-mm, Andrew Morton, linux-kernel

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.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
 fs/proc/task_mmu.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 5589b4bd4b85..d3819beb2d30 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -46,8 +46,11 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
 	if (hiwater_rss < mm->hiwater_rss)
 		hiwater_rss = mm->hiwater_rss;
 
-	text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK)) >> 10;
-	lib = (mm->exec_vm << (PAGE_SHIFT-10)) - text;
+	/* split executable areas between text and lib */
+	text = PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK);
+	text = min(text, mm->exec_vm << PAGE_SHIFT);
+	lib = (mm->exec_vm << PAGE_SHIFT) - text;
+
 	swap = get_mm_counter(mm, MM_SWAPENTS);
 	ptes = PTRS_PER_PTE * sizeof(pte_t) * atomic_long_read(&mm->nr_ptes);
 	pmds = PTRS_PER_PMD * sizeof(pmd_t) * mm_nr_pmds(mm);
@@ -78,7 +81,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
 		file << (PAGE_SHIFT-10),
 		shmem << (PAGE_SHIFT-10),
 		mm->data_vm << (PAGE_SHIFT-10),
-		mm->stack_vm << (PAGE_SHIFT-10), text, lib,
+		mm->stack_vm << (PAGE_SHIFT-10),
+		text >> 10,
+		lib >> 10,
 		ptes >> 10,
 		pmds >> 10,
 		swap << (PAGE_SHIFT-10));

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] proc: do not show VmExe bigger than total executable virtual memory
@ 2017-10-06 11:32 ` Konstantin Khlebnikov
  0 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2017-10-06 11:32 UTC (permalink / raw)
  To: linux-mm, Andrew Morton, linux-kernel

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.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
 fs/proc/task_mmu.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 5589b4bd4b85..d3819beb2d30 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -46,8 +46,11 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
 	if (hiwater_rss < mm->hiwater_rss)
 		hiwater_rss = mm->hiwater_rss;
 
-	text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK)) >> 10;
-	lib = (mm->exec_vm << (PAGE_SHIFT-10)) - text;
+	/* split executable areas between text and lib */
+	text = PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK);
+	text = min(text, mm->exec_vm << PAGE_SHIFT);
+	lib = (mm->exec_vm << PAGE_SHIFT) - text;
+
 	swap = get_mm_counter(mm, MM_SWAPENTS);
 	ptes = PTRS_PER_PTE * sizeof(pte_t) * atomic_long_read(&mm->nr_ptes);
 	pmds = PTRS_PER_PMD * sizeof(pmd_t) * mm_nr_pmds(mm);
@@ -78,7 +81,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
 		file << (PAGE_SHIFT-10),
 		shmem << (PAGE_SHIFT-10),
 		mm->data_vm << (PAGE_SHIFT-10),
-		mm->stack_vm << (PAGE_SHIFT-10), text, lib,
+		mm->stack_vm << (PAGE_SHIFT-10),
+		text >> 10,
+		lib >> 10,
 		ptes >> 10,
 		pmds >> 10,
 		swap << (PAGE_SHIFT-10));

--
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>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory
  2017-10-06 11:32 ` Konstantin Khlebnikov
@ 2017-10-10 22:25   ` Andrew Morton
  -1 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2017-10-10 22:25 UTC (permalink / raw)
  To: Konstantin Khlebnikov; +Cc: linux-mm, linux-kernel

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"?

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?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory
@ 2017-10-10 22:25   ` Andrew Morton
  0 siblings, 0 replies; 8+ messages in thread
From: Andrew Morton @ 2017-10-10 22:25 UTC (permalink / raw)
  To: Konstantin Khlebnikov; +Cc: linux-mm, linux-kernel

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"?

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?

--
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>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory
  2017-10-10 22:25   ` Andrew Morton
@ 2017-10-11  7:00     ` Konstantin Khlebnikov
  -1 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2017-10-11  7:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, linux-kernel

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory
@ 2017-10-11  7:00     ` Konstantin Khlebnikov
  0 siblings, 0 replies; 8+ messages in thread
From: Konstantin Khlebnikov @ 2017-10-11  7:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, linux-kernel

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>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory
  2017-10-11  7:00     ` Konstantin Khlebnikov
@ 2017-12-01 17:25       ` Vlastimil Babka
  -1 siblings, 0 replies; 8+ messages in thread
From: Vlastimil Babka @ 2017-12-01 17:25 UTC (permalink / raw)
  To: Konstantin Khlebnikov, Andrew Morton; +Cc: linux-mm, linux-kernel

On 10/11/2017 09:00 AM, Konstantin Khlebnikov wrote:
> 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.

Please add this to changelog. I agree that it's better/safer after your
patch. These counters are fundamentally heuristics so we can't guarantee
"proper" values for weird binaries. exec_vm OTOH is an objective value
so it makes sense to use it as a safe boundary.

Acked-by: Vlastimil Babka <vbabka@suse.cz>

>>
>> 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>
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] proc: do not show VmExe bigger than total executable virtual memory
@ 2017-12-01 17:25       ` Vlastimil Babka
  0 siblings, 0 replies; 8+ messages in thread
From: Vlastimil Babka @ 2017-12-01 17:25 UTC (permalink / raw)
  To: Konstantin Khlebnikov, Andrew Morton; +Cc: linux-mm, linux-kernel

On 10/11/2017 09:00 AM, Konstantin Khlebnikov wrote:
> 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.

Please add this to changelog. I agree that it's better/safer after your
patch. These counters are fundamentally heuristics so we can't guarantee
"proper" values for weird binaries. exec_vm OTOH is an objective value
so it makes sense to use it as a safe boundary.

Acked-by: Vlastimil Babka <vbabka@suse.cz>

>>
>> 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>
> 

--
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>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-12-01 17:26 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-06 11:32 [PATCH] proc: do not show VmExe bigger than total executable virtual memory Konstantin Khlebnikov
2017-10-06 11:32 ` Konstantin Khlebnikov
2017-10-10 22:25 ` Andrew Morton
2017-10-10 22:25   ` Andrew Morton
2017-10-11  7:00   ` Konstantin Khlebnikov
2017-10-11  7:00     ` Konstantin Khlebnikov
2017-12-01 17:25     ` Vlastimil Babka
2017-12-01 17:25       ` Vlastimil Babka

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.