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  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.

Powered by blists - more mailing lists