linux-kernel - Re: [PATCH 2/2] Add /proc/PID/{smaps, numa

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: <20171026143133.7rm5wcgikjgmx4sc@dhcp22.suse.cz>
Date:   Thu, 26 Oct 2017 16:31:33 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Fan Du <fan.du@...el.com>, akpm@...ux-foundation.org, hch@....de,
        dan.j.williams@...el.com, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org
Subject: Re: [PATCH 2/2] Add /proc/PID/{smaps, numa_maps} support for DAX

On Thu 26-10-17 07:24:14, Dave Hansen wrote:
> On 10/26/2017 07:16 AM, Michal Hocko wrote:
> >> The original motivation was for DAX.  They have parallel large page
> >> infrastructure separate from hugetlbfs and THP.  Their constraints about
> >> when they can use large pages differ from the normal mm cases, so it is
> >> hard to tell when large pages are in use.  For instance, the file on
> >> *disk* has to be 2MB contiguous and aligned to map with 2MB pages even
> >> if the mmap() address is >2MB and 2MB-aligned.
> > 
> > I assume there is some tool which is going to use this information?
> 
> Actually, I don't remember whether it was tooling or just confused
> humans.  I *think* Dan was trying to write test cases for huge page DAX
> support and couldn't figure out whether or not it was using large pages.

That sounds like a very weak justification to adding new stuff to smaps
to be honest.

> >> But, in general, this seems like the thing that we probably should have
> >> done in the first place for THP.  It's a lot more generic and does not
> >> require someone reading the file to know what the particular
> >> architecture's page sizes are.
> > 
> > I fully agree. This just shows how single usecase focus driven smaps
> > file was. That is why I am asking about usecases when somebody want to
> > try yet another special field there. Smaps has become a dump of of
> > special cases which is not really easy to understand and so people tend
> > to use it incorrectly.
> 
> We just have to be careful not to cram use-cases into the existing
> fields which might make them meaningless.  I fear that Fan Du's latest
> patches do that.

Not only that. There have been reports that reading smaps is too
expensive. Curiously enough the overhead doesn't come up from
the data collection but rather copying to the userspace. So we should be
careful to not print data that is not of general use.

-- 
Michal Hocko
SUSE Labs