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] [day] [month] [year] [list]

Date:   Thu, 4 May 2017 14:08:12 +0000
From:   "Kani, Toshimitsu" <toshi.kani@....com>
To:     "dan.j.williams@...el.com" <dan.j.williams@...el.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dave.jiang@...el.com" <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, 2017-05-03 at 19:01 -0700, Dan Williams wrote:
> 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.com> wrote:
> > > > > On Wed, May 3, 2017 at 3:41 PM, Kani, Toshimitsu
> > > > > <toshi.kani@....com> 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/r
> > > > > egion1/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/reg
> > > > ion1/dax1.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/d
> > > ax0.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"

Oh, I see. You are right. Looks like I can use the symbolic link under
"class/dax" to avoid this numbering issue.

# ll /sys/class/dax/dax0.0
lrwxrwxrwx 1 root root 0 May  4 02:55 /sys/class/dax/dax0.0 ->
../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/dax0.1
/dax/dax0.0

> > 
> > 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/dax
> > 0.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.

Right. I was totally confused by the numbering of these files...

Thanks!
-Toshi