linux-kernel - RE: [External] Re: [PATCH v2] libnvdimm, region_devs: stop NDD

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]

Message-ID: <HK0PR03MB317036BE69B40E73896A044189020@HK0PR03MB3170.apcprd03.prod.outlook.com>
Date:   Wed, 5 Sep 2018 03:26:29 +0000
From:   Ocean HY1 He <hehy1@...ovo.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        Ocean He <oceanhehy@...il.com>
CC:     Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Vishal L Verma <vishal.l.verma@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [External]  Re: [PATCH v2] libnvdimm, region_devs: stop
 NDD_ALIASING bit test if one test pass



> -----Original Message-----
> From: Dan Williams <dan.j.williams@...el.com>
> Sent: Tuesday, September 04, 2018 11:58 PM
> To: Ocean He <oceanhehy@...il.com>
> Cc: Ross Zwisler <ross.zwisler@...ux.intel.com>; Vishal L Verma
> <vishal.l.verma@...el.com>; Dave Jiang <dave.jiang@...el.com>; linux-
> nvdimm <linux-nvdimm@...ts.01.org>; Linux Kernel Mailing List <linux-
> kernel@...r.kernel.org>; Ocean HY1 He <hehy1@...ovo.com>
> Subject: [External] Re: [PATCH v2] libnvdimm, region_devs: stop
> NDD_ALIASING bit test if one test pass
> 
> On Tue, Sep 4, 2018 at 3:47 AM, Ocean He <oceanhehy@...il.com> wrote:
> > From: Ocean He <hehy1@...ovo.com>
> >
> > There is no need to finish entire loop to execute NDD_ALIASING bit test
> > against every nvdimm->flags.
> 
> Of course there is. I see nothing stopping someone mixing an NVDIMM
> that supports labels with one that doesn't. 
Hi Dan,
Thanks for your comments.

I only have NVDIMM which supports label, so I could not do this type test yet.
As I understand your words, in mixing status, the nstype would be
ND_DEVICE_NAMESPACE_PMEM if one NVDIMM supports labels. Am I right?

By the way, do you think my patch is valuable to save a few cpu cycles here?

Ocean.
> If anything I think we
> need fixes to make sure this operates correctly to force disable
> BLK-mode capactiy when the PMEM capacity is interleaved with a
> label-less NVDIMM.
I am trying to translate your words to test steps, please correct me for
misunderstanding.
#1. Prepare 2 NVDIMMs which has no label capacity.
#2. Create a region which has PMEM capacity and interleaved.
ipmctl create -f -goal -socket 0x1 PersistentMemoryType=AppDirect
#3. Create a BLK-mode capacity namespace, then this namespace should be 
"force disable" ?
ndctl create-namespace -r region1 -s 1g -t pmem -m sector

Ocean.