* [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same
@ 2018-07-01 18:31 Thomas Lindroth
2018-07-03 7:36 ` Vlastimil Babka
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Lindroth @ 2018-07-01 18:31 UTC (permalink / raw)
To: dancol; +Cc: linux-api, linux-kernel
While looking around in /proc on my v4.14.52 system I noticed that
all processes got a lot of "Locked" memory in /proc/*/smaps. A lot
more memory than a regular user can usually lock with mlock().
commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems
to have changed the behavior of "Locked".
commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317
Author: Daniel Colascione <dancol@google.com>
Date: Wed Sep 6 16:25:08 2017 -0700
mm: add /proc/pid/smaps_rollup
Before that commit the code was like this. Notice the VM_LOCKED
check.
seq_printf(m,
"Size: %8lu kB\n"
"Rss: %8lu kB\n"
"Pss: %8lu kB\n"
"Shared_Clean: %8lu kB\n"
"Shared_Dirty: %8lu kB\n"
"Private_Clean: %8lu kB\n"
"Private_Dirty: %8lu kB\n"
"Referenced: %8lu kB\n"
"Anonymous: %8lu kB\n"
"LazyFree: %8lu kB\n"
"AnonHugePages: %8lu kB\n"
"ShmemPmdMapped: %8lu kB\n"
"Shared_Hugetlb: %8lu kB\n"
"Private_Hugetlb: %7lu kB\n"
"Swap: %8lu kB\n"
"SwapPss: %8lu kB\n"
"KernelPageSize: %8lu kB\n"
"MMUPageSize: %8lu kB\n"
"Locked: %8lu kB\n",
(vma->vm_end - vma->vm_start) >> 10,
mss.resident >> 10,
(unsigned long)(mss.pss >> (10 + PSS_SHIFT)),
mss.shared_clean >> 10,
mss.shared_dirty >> 10,
mss.private_clean >> 10,
mss.private_dirty >> 10,
mss.referenced >> 10,
mss.anonymous >> 10,
mss.lazyfree >> 10,
mss.anonymous_thp >> 10,
mss.shmem_thp >> 10,
mss.shared_hugetlb >> 10,
mss.private_hugetlb >> 10,
mss.swap >> 10,
(unsigned long)(mss.swap_pss >> (10 + PSS_SHIFT)),
vma_kernel_pagesize(vma) >> 10,
vma_mmu_pagesize(vma) >> 10,
(vma->vm_flags & VM_LOCKED) ?
(unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0);
After that commit Locked is now the same as Pss. This looks like a
mistake.
seq_printf(m,
"Rss: %8lu kB\n"
"Pss: %8lu kB\n"
"Shared_Clean: %8lu kB\n"
"Shared_Dirty: %8lu kB\n"
"Private_Clean: %8lu kB\n"
"Private_Dirty: %8lu kB\n"
"Referenced: %8lu kB\n"
"Anonymous: %8lu kB\n"
"LazyFree: %8lu kB\n"
"AnonHugePages: %8lu kB\n"
"ShmemPmdMapped: %8lu kB\n"
"Shared_Hugetlb: %8lu kB\n"
"Private_Hugetlb: %7lu kB\n"
"Swap: %8lu kB\n"
"SwapPss: %8lu kB\n"
"Locked: %8lu kB\n",
mss->resident >> 10,
(unsigned long)(mss->pss >> (10 + PSS_SHIFT)),
mss->shared_clean >> 10,
mss->shared_dirty >> 10,
mss->private_clean >> 10,
mss->private_dirty >> 10,
mss->referenced >> 10,
mss->anonymous >> 10,
mss->lazyfree >> 10,
mss->anonymous_thp >> 10,
mss->shmem_thp >> 10,
mss->shared_hugetlb >> 10,
mss->private_hugetlb >> 10,
mss->swap >> 10,
(unsigned long)(mss->swap_pss >> (10 + PSS_SHIFT)),
(unsigned long)(mss->pss >> (10 + PSS_SHIFT)));
The latest git has changed a bit but the functionality is the
same.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same 2018-07-01 18:31 [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same Thomas Lindroth @ 2018-07-03 7:36 ` Vlastimil Babka 2018-07-03 7:45 ` Vlastimil Babka 2018-07-03 16:20 ` Daniel Colascione 0 siblings, 2 replies; 5+ messages in thread From: Vlastimil Babka @ 2018-07-03 7:36 UTC (permalink / raw) To: Thomas Lindroth, dancol, Andrew Morton; +Cc: linux-api, linux-kernel, linux-mm +CC On 07/01/2018 08:31 PM, Thomas Lindroth wrote: > While looking around in /proc on my v4.14.52 system I noticed that > all processes got a lot of "Locked" memory in /proc/*/smaps. A lot > more memory than a regular user can usually lock with mlock(). > > commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems > to have changed the behavior of "Locked". > > commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 > Author: Daniel Colascione <dancol@google.com> > Date: Wed Sep 6 16:25:08 2017 -0700 > > mm: add /proc/pid/smaps_rollup > > Before that commit the code was like this. Notice the VM_LOCKED > check. > > seq_printf(m, > "Size: %8lu kB\n" > "Rss: %8lu kB\n" > "Pss: %8lu kB\n" > "Shared_Clean: %8lu kB\n" > "Shared_Dirty: %8lu kB\n" > "Private_Clean: %8lu kB\n" > "Private_Dirty: %8lu kB\n" > "Referenced: %8lu kB\n" > "Anonymous: %8lu kB\n" > "LazyFree: %8lu kB\n" > "AnonHugePages: %8lu kB\n" > "ShmemPmdMapped: %8lu kB\n" > "Shared_Hugetlb: %8lu kB\n" > "Private_Hugetlb: %7lu kB\n" > "Swap: %8lu kB\n" > "SwapPss: %8lu kB\n" > "KernelPageSize: %8lu kB\n" > "MMUPageSize: %8lu kB\n" > "Locked: %8lu kB\n", > (vma->vm_end - vma->vm_start) >> 10, > mss.resident >> 10, > (unsigned long)(mss.pss >> (10 + PSS_SHIFT)), > mss.shared_clean >> 10, > mss.shared_dirty >> 10, > mss.private_clean >> 10, > mss.private_dirty >> 10, > mss.referenced >> 10, > mss.anonymous >> 10, > mss.lazyfree >> 10, > mss.anonymous_thp >> 10, > mss.shmem_thp >> 10, > mss.shared_hugetlb >> 10, > mss.private_hugetlb >> 10, > mss.swap >> 10, > (unsigned long)(mss.swap_pss >> (10 + PSS_SHIFT)), > vma_kernel_pagesize(vma) >> 10, > vma_mmu_pagesize(vma) >> 10, > (vma->vm_flags & VM_LOCKED) ? > (unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0); > > After that commit Locked is now the same as Pss. This looks like a > mistake. > > seq_printf(m, > "Rss: %8lu kB\n" > "Pss: %8lu kB\n" > "Shared_Clean: %8lu kB\n" > "Shared_Dirty: %8lu kB\n" > "Private_Clean: %8lu kB\n" > "Private_Dirty: %8lu kB\n" > "Referenced: %8lu kB\n" > "Anonymous: %8lu kB\n" > "LazyFree: %8lu kB\n" > "AnonHugePages: %8lu kB\n" > "ShmemPmdMapped: %8lu kB\n" > "Shared_Hugetlb: %8lu kB\n" > "Private_Hugetlb: %7lu kB\n" > "Swap: %8lu kB\n" > "SwapPss: %8lu kB\n" > "Locked: %8lu kB\n", > mss->resident >> 10, > (unsigned long)(mss->pss >> (10 + PSS_SHIFT)), > mss->shared_clean >> 10, > mss->shared_dirty >> 10, > mss->private_clean >> 10, > mss->private_dirty >> 10, > mss->referenced >> 10, > mss->anonymous >> 10, > mss->lazyfree >> 10, > mss->anonymous_thp >> 10, > mss->shmem_thp >> 10, > mss->shared_hugetlb >> 10, > mss->private_hugetlb >> 10, > mss->swap >> 10, > (unsigned long)(mss->swap_pss >> (10 + PSS_SHIFT)), > (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); > > The latest git has changed a bit but the functionality is the > same. ----8<---- >From fa721521c981167c24ac8f4be446443d293d741e Mon Sep 17 00:00:00 2001 From: Vlastimil Babka <vbabka@suse.cz> Date: Tue, 3 Jul 2018 09:24:27 +0200 Subject: [PATCH] mm: fix Locked field in /proc/pid/smaps* Thomas reports: : While looking around in /proc on my v4.14.52 system I noticed that : all processes got a lot of "Locked" memory in /proc/*/smaps. A lot : more memory than a regular user can usually lock with mlock(). : : commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems : to have changed the behavior of "Locked". : : Before that commit the code was like this. Notice the VM_LOCKED : check. : : (vma->vm_flags & VM_LOCKED) ? : (unsigned long)(mss.pss >> (10 + PSS_SHIFT)) : 0); : : After that commit Locked is now the same as Pss. This looks like a : mistake. : : (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); Indeed, the commit has added mss->pss_locked with the correct value that depends on VM_LOCKED, but forgot to actually use it. Fix it. Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Cc: stable@vger.kernel.org --- fs/proc/task_mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index e9679016271f..dfd73a4616ce 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -831,7 +831,8 @@ static int show_smap(struct seq_file *m, void *v, int is_pid) SEQ_PUT_DEC(" kB\nSwap: ", mss->swap); SEQ_PUT_DEC(" kB\nSwapPss: ", mss->swap_pss >> PSS_SHIFT); - SEQ_PUT_DEC(" kB\nLocked: ", mss->pss >> PSS_SHIFT); + SEQ_PUT_DEC(" kB\nLocked: ", + mss->pss_locked >> PSS_SHIFT); seq_puts(m, " kB\n"); } if (!rollup_mode) { -- 2.18.0 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same 2018-07-03 7:36 ` Vlastimil Babka @ 2018-07-03 7:45 ` Vlastimil Babka 2018-07-03 16:20 ` Daniel Colascione 1 sibling, 0 replies; 5+ messages in thread From: Vlastimil Babka @ 2018-07-03 7:45 UTC (permalink / raw) To: Thomas Lindroth, dancol, Andrew Morton; +Cc: linux-api, linux-kernel, linux-mm On 07/03/2018 09:36 AM, Vlastimil Babka wrote: > On 07/01/2018 08:31 PM, Thomas Lindroth wrote: >> While looking around in /proc on my v4.14.52 system I noticed that >> all processes got a lot of "Locked" memory in /proc/*/smaps. A lot >> more memory than a regular user can usually lock with mlock(). >> >> commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems >> to have changed the behavior of "Locked". Oops, I forgot, thanks for the nice report :) Vlastimil ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same 2018-07-03 7:36 ` Vlastimil Babka 2018-07-03 7:45 ` Vlastimil Babka @ 2018-07-03 16:20 ` Daniel Colascione 2018-07-04 8:46 ` Vlastimil Babka 1 sibling, 1 reply; 5+ messages in thread From: Daniel Colascione @ 2018-07-03 16:20 UTC (permalink / raw) To: Vlastimil Babka Cc: Thomas Lindroth, Andrew Morton, linux-api, linux-kernel, linux-mm On Tue, Jul 3, 2018 at 12:36 AM, Vlastimil Babka <vbabka@suse.cz> wrote: > +CC > > On 07/01/2018 08:31 PM, Thomas Lindroth wrote: >> While looking around in /proc on my v4.14.52 system I noticed that >> all processes got a lot of "Locked" memory in /proc/*/smaps. A lot >> more memory than a regular user can usually lock with mlock(). >> >> commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems >> to have changed the behavior of "Locked". Thanks for fixing that. I submitted a patch [1] for this bug and some others a while ago, but the patch didn't make it into the tree because or wasn't split up correctly or something, and I had to do other work. [1] https://marc.info/?l=linux-mm&m=151927723128134&w=2 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same 2018-07-03 16:20 ` Daniel Colascione @ 2018-07-04 8:46 ` Vlastimil Babka 0 siblings, 0 replies; 5+ messages in thread From: Vlastimil Babka @ 2018-07-04 8:46 UTC (permalink / raw) To: Daniel Colascione Cc: Thomas Lindroth, Andrew Morton, linux-api, linux-kernel, linux-mm On 07/03/2018 06:20 PM, Daniel Colascione wrote: > On Tue, Jul 3, 2018 at 12:36 AM, Vlastimil Babka <vbabka@suse.cz> wrote: >> +CC >> >> On 07/01/2018 08:31 PM, Thomas Lindroth wrote: >>> While looking around in /proc on my v4.14.52 system I noticed that >>> all processes got a lot of "Locked" memory in /proc/*/smaps. A lot >>> more memory than a regular user can usually lock with mlock(). >>> >>> commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems >>> to have changed the behavior of "Locked". > > Thanks for fixing that. I submitted a patch [1] for this bug and some > others a while ago, but the patch didn't make it into the tree because > or wasn't split up correctly or something, and I had to do other work. Hmm I see. I pondered about the patch and wondered if the scenarios it fixes are really possible for smaps_rollup. Did you observe them in practice? Namely: - when seq_file starts and stops multiple times on a single open file description - when it issues multiple show calls for the same iterator value I don't think it can happen when all positions but the last one just return SEQ_SKIP. Anyway I think the seq_file iterator API usage for smaps_rollup is unnecessary. Semantically the file shows only one "element" and that's the set of rollup values for all vmas. Letting seq_file do the iteration over vmas brings only complications? > [1] https://marc.info/?l=linux-mm&m=151927723128134&w=2 > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-04 8:46 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-01 18:31 [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same Thomas Lindroth 2018-07-03 7:36 ` Vlastimil Babka 2018-07-03 7:45 ` Vlastimil Babka 2018-07-03 16:20 ` Daniel Colascione 2018-07-04 8:46 ` Vlastimil Babka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).