linux-kernel - Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of dimms while region active

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:	Mon, 6 Jun 2016 12:46:41 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Linda Knippers <linda.knippers@....com>
Cc:	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	david <david@...morbit.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 01/13] driver core, libnvdimm: disable manual unbind of
 dimms while region active

On Mon, Jun 6, 2016 at 12:36 PM, Linda Knippers <linda.knippers@....com> wrote:
>
>
> On 6/6/2016 3:31 PM, Dan Williams wrote:
>> On Mon, Jun 6, 2016 at 12:25 PM, Linda Knippers <linda.knippers@....com> wrote:
>>> On 6/4/2016 4:52 PM, Dan Williams wrote:
>>>> There are scenarios where we need a middle ground between disabling all
>>>> manual bind/unbind attempts (via driver->suppress_bind_attrs) and
>>>> allowing unbind at any userspace-determined time.  Pinning modules takes
>>>> away one vector for unwanted out-of-sequence device_release_driver()
>>>> invocations, this new mechanism (via device->suppress_unbind_attr) takes
>>>> away another.
>>>>
>>>> The first user of this mechanism is the libnvdimm sub-system where
>>>> manual dimm disabling should be prevented while the dimm is active in
>>>> any region.  Note that there is a 1:N dimm-to-region relationship which
>>>> is why this is implemented as a disable count rather than a flag.  This
>>>> forces userspace to disable regions before dimms when manually shutting
>>>> down a bus topology.
>>>
>>> How is this related to deprecating pcommit?
>>
>> We need guarantees that the flush hint mappings are valid for the
>> duration of a pmem namespace being enabled.  I am going to move the
>> mapping of the flush hint region from per-dimm to per-region.  However
>> since multiple regions may reference the same dimm the mapping needs
>> to be reference counted and shared across regions.  This will be
>> similar to the arrangement we have for BLK-regions that share a
>> control region mapping.
>
> Why are things moving around?  Aren't flush hints defined per NFIT device
> handle, making them an optional per-dimm thing?
>
> I don't understand a lot of this patch series and had the same questions
> as Jeff.  How does deprecating pcommit, because it's not necessary with ADR,
> change so much?

This patch set deprecates pcommit, and introduces the usage of flush
hints into the pmem path.  The introduction patch used the word
"usually", I should have fleshed that out to say "usually ADR, or
explicit use of flush hints".

A solution to the posted-write-queue flushing needs to be available
and a platform can choose to use flush hints or ADR.  If the NFIT
defines an NVDIMM device without hints we assume the platform must
have ADR.  If the platform NFIT neglects to define an NVDIMM to
physical address range mapping, we warn about a potentially broken
BIOS.  Hopefully we can make this clearer in future versions of the
spec.