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:	Wed, 29 Apr 2015 02:25:04 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	linux-nvdimm@...ts.01.org, Boaz Harrosh <boaz@...xistor.com>,
	Neil Brown <neilb@...e.de>, Dave Chinner <david@...morbit.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	Christoph Hellwig <hch@....de>, linux-acpi@...r.kernel.org,
	Jeff Moyer <jmoyer@...hat.com>,
	Nicholas Moulin <nicholas.w.moulin@...ux.intel.com>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Vishal Verma <vishal.l.verma@...ux.intel.com>,
	Jens Axboe <axboe@...com>, Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 00/20] libnd: non-volatile memory device support

On Tuesday, April 28, 2015 02:24:12 PM Dan Williams wrote:
> Changes since v1 [1]: Incorporates feedback received prior to April 24.
> 
> 1/ Ingo said [2]:
> 
>        "So why on earth is this whole concept and the naming itself
>        ('drivers/block/nd/' stands for 'NFIT Defined', apparently)
>        revolving around a specific 'firmware' mindset and revolving
>        around specific, weirdly named, overly complicated looking
>        firmware interfaces that come with their own new weird
>        glossary??"
> 
>    Indeed, we of course consulted the NFIT specification to determine
>    the shape of the sub-system, but then let its terms and data
>    structures permeate too deep into the implementation.  That is fixed
>    now with all NFIT specifics factored out into acpi.c.  The NFIT is no
>    longer required reading to review libnd.  Only three concepts are
>    needed:
> 
>       i/ PMEM - contiguous memory range where cpu stores are
> 	 persistent once they are flushed through the memory
>          controller.
> 
>      ii/ BLK - mmio apertures (sliding windows) that can be
> 	 programmed to access an aperture's-worth of persistent
>          media at a time.
> 
>     iii/ DPA - "dimm-physical-address", address space local to a
> 	 dimm.  A dimm may provide both PMEM-mode and BLK-mode
> 	 access to a range of DPA.  libnd manages allocation of DPA
>          to either PMEM or BLK-namespaces to resolve this aliasing. 
> 
>    The v1..v2 diffstat below shows the migration of nfit-specifics to
>    acpi.c and the new state of libnd being nfit-free.  "nd" now only
>    refers to "non-volatile devices".  Note, reworked documentation will
>    return once the review has settled.
> 
>    Documentation/blockdev/nd.txt     |  867 ---------------------
>    MAINTAINERS                       |   34 +-
>    arch/ia64/kernel/efi.c            |    5 +-
>    arch/x86/kernel/e820.c            |   11 +-
>    arch/x86/kernel/pmem.c            |    2 +-
>    drivers/block/Makefile            |    2 +-
>    drivers/block/nd/Kconfig          |  135 ++--
>    drivers/block/nd/Makefile         |   32 +-
>    drivers/block/nd/acpi.c           | 1506 +++++++++++++++++++++++++++++++------
>    drivers/block/nd/acpi_nfit.h      |  321 ++++++++
>    drivers/block/nd/blk.c            |   27 +-
>    drivers/block/nd/btt.c            |    6 +-
>    drivers/block/nd/btt_devs.c       |    8 +-
>    drivers/block/nd/bus.c            |  337 +++++----
>    drivers/block/nd/core.c           |  574 +-------------
>    drivers/block/nd/dimm.c           |   11 -
>    drivers/block/nd/dimm_devs.c      |  292 ++-----
>    drivers/block/nd/e820.c           |  100 +++
>    drivers/block/nd/libnd.h          |  122 +++
>    drivers/block/nd/namespace_devs.c |   10 +-
>    drivers/block/nd/nd-private.h     |  107 +--
>    drivers/block/nd/nd.h             |   91 +--
>    drivers/block/nd/nfit.h           |  238 ------
>    drivers/block/nd/pmem.c           |   56 +-
>    drivers/block/nd/region.c         |   78 +-
>    drivers/block/nd/region_devs.c    |  783 +++----------------
>    drivers/block/nd/test/iomap.c     |   86 +--
>    drivers/block/nd/test/nfit.c      | 1115 +++++++++++++++------------
>    drivers/block/nd/test/nfit_test.h |   15 +-
>    include/uapi/linux/ndctl.h        |  130 ++--
>    30 files changed, 3166 insertions(+), 3935 deletions(-)
>    delete mode 100644 Documentation/blockdev/nd.txt
>    create mode 100644 drivers/block/nd/acpi_nfit.h
>    create mode 100644 drivers/block/nd/e820.c
>    create mode 100644 drivers/block/nd/libnd.h
>    delete mode 100644 drivers/block/nd/nfit.h
> 
>    [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-April/000484.html
>    [2]: https://lists.01.org/pipermail/linux-nvdimm/2015-April/000520.html
> 
> 2/ Christoph asked the pmem ida conversion to be moved to its own patch
>    (done), and to consider leaving the current pmem.c in drivers/block/.
>    Instead, I converted the e820-type-12 enabling to be the first
>    non-ACPI-NFIT based consumer of libnd.  The new nd_e820 driver simply
>    registers e820-type-12 ranges as libnd PMEM regions.  Among other
>    things this conversion enables BTT for these ranges.  The alternative
>    is to move drivers/block/nd/nd.h internals out to include/linux/
>    which I think is worse.
> 
> 3/ Toshi reported that the NFIT parsing fails to handle the case of a
>    PMEM range with a single-dimm (non-aliasing) interleave description.
>    Support for this case was added and is tested by default by the
>    nfit_test.1 configuration.
> 
> 4/ Toshi reported that we should not be treating a missing _STA property
>    as a "dimm disabled by firmware" case.  (fixed).
> 
> 5/ Christoph noted that ND_ARCH_HAS_IOREMAP_CACHE needs to be moved to
>    arch code.  It is gone for now and we'll revisit when adding cached
>    mappings back to the PMEM driver.
> 
> 6/ Toshi mentioned that the presence of two different nd_bus_probe()
>    functions was confusing.  (cleaned up).
> 
> 7/ Robert asked for s/btt_checksum/nd_btt_checksum/ (done).
> 
> 8/ Linda asked for nfit_test to honor dynamic cma reservations via the
>    cma= command line (done).  The cma requirements have also been
>    reduced to 128M as only the simulated DAX regions need CMA.  The rest
>    can use vmalloc().
> 
> ---
> 
> Available here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm nd-v2
> 
> ---
> 
> Dan Williams (18):
>       e820, efi: add ACPI 6.0 persistent memory types
>       libnd, nd_acpi: initial libnd infrastructure and NFIT support
>       nd_acpi, nfit-test: manufactured NFITs for interface development
>       libnd: ndctl class device, and nd bus attributes
>       libnd, nd_acpi: dimm/memory-devices
>       libnd: ndctl.h, the nd ioctl abi
>       libnd, nd_dimm: dimm driver and base libnd device-driver infrastructure
>       libnd, nd_acpi: regions (block-data-window, persistent memory, volatile memory)
>       libnd: support for legacy (non-aliasing) nvdimms
>       pmem: use ida
>       libnd, nd_pmem: add libnd support to the pmem driver
>       libnd, nd_acpi: add interleave-set state-tracking infrastructure
>       libnd: namespace indices: read and validate
>       libnd: pmem label sets and namespace instantiation.
>       libnd: blk labels and namespace instantiation
>       libnd: write pmem label set
>       libnd: write blk label set
>       libnd: infrastructure for btt devices
> 
> Ross Zwisler (1):
>       libnd, nd_acpi, nd_blk: driver for BLK-mode access persistent memory
> 
> Vishal Verma (1):
>       nd_btt: atomic sector updates

I'm wondering what's wrong with CCing all of the series to linux-acpi?

Is there anything in it that the people on that list should not see, by any
chance?

Like patch [01/20], for the most obvious example.  It even has "ACPI 6" in the
subject ...

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ