linux-kernel - Re: [PATCH] add "VmUsers: N" to /proc/$PID/status

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <63188.1247786645@turing-police.cc.vt.edu>
Date:	Thu, 16 Jul 2009 19:24:05 -0400
From:	Valdis.Kletnieks@...edu
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] add "VmUsers: N" to /proc/$PID/status

On Thu, 16 Jul 2009 23:27:25 +0200, Denys Vlasenko said:

> You are right. There is more: the truly accurate accounting
> needs to be per page. Like /proc/$PID/smaps
> and /proc/$PID/pagemap. (However, I am not sure you can
> relize that two processes share a VM by looking
> at these files either)

Hmm.. what if /proc/$PID/<something> reported pairs of virtual/real page
addresses? Then you could identify shared pages by virtue of them having
the same real page frame address..

Of course, with 2G of memory in my laptop, that's 256K 4K pages, and it gets
even messier on machines with macho-RAM installed and lots of processes
running. Lotta pain to get more accurate numbers on what is a very race-prone
number.

> I, indeed, want to have just an N I can divide RSS/VSZ/etc by,
> to get, say, top display which do not mislead user
> into thinking that he has 3 processes with 100 megabyte RSS
> when in reality he has 3 processes sharing a single VM
> with 100 meg RSS.

Thinking about it a bit more - it's probably *usually* possible to sort out
which processes are sharing because if you have 2 sets of shared memory,
they'll *usually* have different RSS values - so the 2 processes with a
count of 2 and an RSS of 179M are one set, and the 2 processes with a count
of 2 and an RSS of 198M are probably another.

Certainly not good enough for chargeback accounting, but good enough if you're
trying to debug a WTF? situation or other "what's going on?" question...

Content of type "application/pgp-signature" skipped