linux-kernel - Re: [PATCH v4] Add /proc/PID/smaps support for DAX

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]

Date:   Fri, 27 Oct 2017 11:26:26 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     "Du, Fan" <fan.du@...el.com>
Cc:     "Hansen, Dave" <dave.hansen@...el.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hch@....de" <hch@....de>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] Add /proc/PID/smaps support for DAX

On Fri 27-10-17 09:17:07, Du, Fan wrote:
[...]
> >But you cannot touch rss and pss because you are going to break existing
> >users as Dave already pointed out. 
> 
> Why it will break something? Do you mind to elaborate?
> The vma part of each smaps portion has associated file if does exist,
> The user spaces monitoring tools will definitely check this field.

Because there are tools which evaluate rss and pss as the real _memory_
consumption. If you put non-ram based memory there you would confuse
them and they would do wrong decisions. In fact we do not even include
all the RAM based memory there. For example hugetlb pages are not
involved and have their separate counter because there are tools which
would misjudge processes with large hugetlb mapping - e.g. kill them as
excessive consumers without any memory returned back to the system.

While all this is really far from ideal, this is how the userspace work
and we are not breaking existing usecases.

-- 
Michal Hocko
SUSE Labs