linux-kernel - Re: [RFC PATCH] dax: add badblocks check to Device 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]

Message-ID: <CAPcyv4i5_6gNRAipcuV2fk2OpfgXD1gY-Q-Zh-re7j=AODSLZA@mail.gmail.com>
Date:   Wed, 3 May 2017 19:01:22 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Kani, Toshimitsu" <toshi.kani@....com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
Subject: Re: [RFC PATCH] dax: add badblocks check to Device DAX

On Wed, May 3, 2017 at 4:36 PM, Kani, Toshimitsu <toshi.kani@....com> wrote:
> On Wed, 2017-05-03 at 17:25 -0600, Toshi Kani wrote:
>> On Wed, 2017-05-03 at 16:08 -0700, Dan Williams wrote:
>> > On Wed, May 3, 2017 at 3:51 PM, Dan Williams <dan.j.williams@...el.
>> > co
>> > m> wrote:
>> > > On Wed, May 3, 2017 at 3:41 PM, Kani, Toshimitsu <toshi.kani@....
>> > > co
>> > > m> wrote:
>> > > > On Wed, 2017-05-03 at 14:48 -0700, Dan Williams wrote:
>>
>>  :
>> > >
>> > > I believe we already have all the data needed to calculate the
>> > > data
>> > > offset. Given the following sysfs path:
>> > >
>> > >     /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/regio
>> > > n1
>> > > /dax1.1/dax/dax1.0
>> > >
>> > > ...we can find the associated namespace device from that dax1.1.
>> > > From
>> > > there we have the base address of the namespace and the size
>> > > device-dax instance.
>> > >
>> > >     device_dax_data_offset == namespace_base + namespace_size -
>> > > device_dax_size
>> >
>> > Dave reminds me that we do have the data offset of the device-dax
>> > instance at the libnvdimm level:
>> >
>> >     /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region1
>> > /d
>> > ax1.1/resource
>> >
>> > ...in this example, which maps to ndctl_dax_get_resource().
>>
>> Thanks for the info!  I noticed why I did not catch this info before.
>>
>> # ll /dev/dax*
>> crw------- 1 root root 251, 3 May  3 04:28 /dev/dax0.0
>>
>> # pwd
>> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/dax0.
>> 0
>>
>> # grep . *
>> align:2097152
>> devtype:nd_dax
>> modalias:nd:t7
>> mode:none
>> numa_node:0
>> grep: power: Is a directory
>> grep: resource: No such device or address
>> grep: size: No such device or address
>> grep: subsystem: Is a directory
>> uevent:DEVTYPE=nd_dax
>> uevent:MODALIAS=nd:t7
>>
>> But I noticed that "resource" and "size" that are under
>> ".../region0/dax0.1" work.  Is this intended?

You mean that region0/dax0.1 and region0/dax0.1/dax/dax0.0 are
functional, but region0/dax0.0 is not? Yes, that is expected the
libnvdimm "struct nd_dax" device is on a different device numbering
scheme than the "struct dev_dax" instance. Depending on load and
namespace reconfiguration order you can expect those names to not
match. The dev_dax instance name is "dax region id"."sub-division
instance"

>
> Here is an output from dax0.1 (I removed the size value).  Noticed that
> mode is different.
>
> # pwd
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/dax0.1
>
> # grep . *
> align:2097152
> grep: dax: Is a directory
> grep: dax_region: Is a directory
> devtype:nd_dax
> grep: driver: Is a directory
> modalias:nd:t7
> mode:pmem
> namespace:namespace0.0
> numa_node:0
> grep: power: Is a directory
> resource:0x250200000
> size:(size value)
> grep: subsystem: Is a directory
> uevent:DEVTYPE=nd_dax
> uevent:DRIVER=dax_pmem
> uevent:MODALIAS=nd:t7
> uuid:8c71811f-260d-4788-8487-db88d829d393

The "mode" in this instance is the mode for the struct page
allocation, i.e. whether it is coming from main memory "mem" or the
persistent memory itself "pmem" in this case.