summaryrefslogtreecommitdiff
path: root/fs/autofs
diff options
context:
space:
mode:
authorVlastimil Babka <vbabka@suse.cz>2018-07-13 16:58:56 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2018-07-14 11:11:09 -0700
commite70cc2bd579e8a9d6d153762f0fe294d0e652ff0 (patch)
tree7e1c2eb92b2cfe17a3980a4430b6cc85ad755801 /fs/autofs
parentbce73e4842390f7b7309c8e253e139db71288ac3 (diff)
downloadlwn-e70cc2bd579e8a9d6d153762f0fe294d0e652ff0.tar.gz
lwn-e70cc2bd579e8a9d6d153762f0fe294d0e652ff0.zip
fs/proc/task_mmu.c: 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 493b0e9d945f (in 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: (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); This looks like a mistake." 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. Link: http://lkml.kernel.org/r/ebf6c7fb-fec3-6a26-544f-710ed193c154@suse.cz Fixes: 493b0e9d945f ("mm: add /proc/pid/smaps_rollup") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Daniel Colascione <dancol@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/autofs')
0 files changed, 0 insertions, 0 deletions