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]

Date:   Thu, 26 Oct 2017 08:56:08 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Dave Hansen <dave.hansen@...el.com>, Fan Du <fan.du@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Hellwig <hch@....de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH 2/2] Add /proc/PID/{smaps, numa_maps} support for DAX

On Thu, Oct 26, 2017 at 8:07 AM, Michal Hocko <mhocko@...nel.org> wrote:
> On Thu 26-10-17 07:51:20, Dave Hansen wrote:
>> On 10/26/2017 07:31 AM, Michal Hocko wrote:
>> > On Thu 26-10-17 07:24:14, Dave Hansen wrote:
>> >> 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.
>>
>> Yep, agreed.  It can't go in _just_ for DAX, and Fan and the other DAX
>> folks need to elaborate on their needs here.
>>
>> Do you have any better ideas?  If we did this, we could probably make an
>> argument that the AnonHuge fields could go away some day.  They haven't
>> always been there.
>
> Yeah, if there is an effective way to see large mappings within the
> range then AnonHuge should probably go away. If that is possible due to
> userspace regressions...
>
>> The only other alternative I can think of are truly DAX-specific
>> interfaces, which also seem like a really bad idea.
>
> Well, if this is mostly for debugging purposes then why not?

I should have recalled this sooner, but for device-dax we don't need
smaps support because the mapping type is enforced by the device. I.e.
if you set the alignment to 2MB you are guaranteed to either get PMD
mappings or SIGBUS. Filesystem DAX is where things are more dynamic,
but because they are dynamic smaps is only an ephemeral answer.