1. 30 6月, 2015 1 次提交
  2. 26 6月, 2015 19 次提交
    • R
      arch, x86: pmem api for ensuring durability of persistent memory updates · 61031952
      Ross Zwisler 提交于
      Based on an original patch by Ross Zwisler [1].
      
      Writes to persistent memory have the potential to be posted to cpu
      cache, cpu write buffers, and platform write buffers (memory controller)
      before being committed to persistent media.  Provide apis,
      memcpy_to_pmem(), wmb_pmem(), and memremap_pmem(), to write data to
      pmem and assert that it is durable in PMEM (a persistent linear address
      range).  A '__pmem' attribute is added so sparse can track proper usage
      of pointers to pmem.
      
      This continues the status quo of pmem being x86 only for 4.2, but
      reworks to ioremap, and wider implementation of memremap() will enable
      other archs in 4.3.
      
      [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-May/000932.html
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      [djbw: various reworks]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      61031952
    • T
      libnvdimm: Add sysfs numa_node to NVDIMM devices · 74ae66c3
      Toshi Kani 提交于
      Add support of sysfs 'numa_node' to I/O-related NVDIMM devices
      under /sys/bus/nd/devices, regionN, namespaceN.0, and bttN.x.
      
      An example of numa_node values on a 2-socket system with a single
      NVDIMM range on each socket is shown below.
        /sys/bus/nd/devices
        |-- btt0.0/numa_node:0
        |-- btt1.0/numa_node:1
        |-- btt1.1/numa_node:1
        |-- namespace0.0/numa_node:0
        |-- namespace1.0/numa_node:1
        |-- region0/numa_node:0
        |-- region1/numa_node:1
      
      These numa_node files are then linked under the block class of
      their device names.
        /sys/class/block/pmem0/device/numa_node:0
        /sys/class/block/pmem1s/device/numa_node:1
      
      This enables numactl(8) to accept 'block:' and 'file:' paths of
      pmem and btt devices as shown in the examples below.
        numactl --preferred block:pmem0 --show
        numactl --preferred file:/dev/pmem1s --show
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      74ae66c3
    • T
      libnvdimm: Set numa_node to NVDIMM devices · 41d7a6d6
      Toshi Kani 提交于
      ACPI NFIT table has System Physical Address Range Structure entries that
      describe a proximity ID of each range when ACPI_NFIT_PROXIMITY_VALID is
      set in the flags.
      
      Change acpi_nfit_register_region() to map a proximity ID to its node ID,
      and set it to a new numa_node field of nd_region_desc, which is then
      conveyed to the nd_region device.
      
      The device core arranges for btt and namespace devices to inherit their
      node from their parent region.
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      [djbw: move set_dev_node() from region.c to bus.c]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      41d7a6d6
    • T
      acpi: Add acpi_map_pxm_to_online_node() · 99759869
      Toshi Kani 提交于
      The kernel initializes CPU & memory's NUMA topology from ACPI
      SRAT table.  Some other ACPI tables, such as NFIT and DMAR, also
      contain proximity IDs for their device's NUMA topology.  This
      information can be used to improve performance of these devices.
      
      This patch introduces acpi_map_pxm_to_online_node(), which is
      similar to acpi_map_pxm_to_node(), but always returns an online
      node.  When the mapped node from a given proximity ID is offline,
      it looks up the node distance table and returns the nearest
      online node.
      
      ACPI device drivers, which are called after the NUMA initialization
      has completed in the kernel, can call this interface to obtain their
      device NUMA topology from ACPI tables.  Such drivers do not have to
      deal with offline nodes.  A node may be offline when a device
      proximity ID is unique, SRAT memory entry does not exist, or NUMA is
      disabled, ex. "numa=off" on x86.
      
      This patch also moves the pxm range check from acpi_get_node() to
      acpi_map_pxm_to_node().
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com&gt;>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      99759869
    • D
      libnvdimm, nfit: handle unarmed dimms, mark namespaces read-only · 58138820
      Dan Williams 提交于
      Upon detection of an unarmed dimm in a region, arrange for descendant
      BTT, PMEM, or BLK instances to be read-only.  A dimm is primarily marked
      "unarmed" via flags passed by platform firmware (NFIT).
      
      The flags in the NFIT memory device sub-structure indicate the state of
      the data on the nvdimm relative to its energy source or last "flush to
      persistence".  For the most part there is nothing the driver can do but
      advertise the state of these flags in sysfs and emit a message if
      firmware indicates that the contents of the device may be corrupted.
      However, for the case of ACPI_NFIT_MEM_ARMED, the driver can arrange for
      the block devices incorporating that nvdimm to be marked read-only.
      This is a safe default as the data is still available and new writes are
      held off until the administrator either forces read-write mode, or the
      energy source becomes armed.
      
      A 'read_only' attribute is added to REGION devices to allow for
      overriding the default read-only policy of all descendant block devices.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      58138820
    • R
      libnvdimm, nfit, nd_blk: driver for BLK-mode access persistent memory · 047fc8a1
      Ross Zwisler 提交于
      The libnvdimm implementation handles allocating dimm address space (DPA)
      between PMEM and BLK mode interfaces.  After DPA has been allocated from
      a BLK-region to a BLK-namespace the nd_blk driver attaches to handle I/O
      as a struct bio based block device. Unlike PMEM, BLK is required to
      handle platform specific details like mmio register formats and memory
      controller interleave.  For this reason the libnvdimm generic nd_blk
      driver calls back into the bus provider to carry out the I/O.
      
      This initial implementation handles the BLK interface defined by the
      ACPI 6 NFIT [1] and the NVDIMM DSM Interface Example [2] composed from
      DCR (dimm control region), BDW (block data window), IDT (interleave
      descriptor) NFIT structures and the hardware register format.
      [1]: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
      [2]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      047fc8a1
    • V
      nd_btt: atomic sector updates · 5212e11f
      Vishal Verma 提交于
      BTT stands for Block Translation Table, and is a way to provide power
      fail sector atomicity semantics for block devices that have the ability
      to perform byte granularity IO. It relies on the capability of libnvdimm
      namespace devices to do byte aligned IO.
      
      The BTT works as a stacked blocked device, and reserves a chunk of space
      from the backing device for its accounting metadata. It is a bio-based
      driver because all IO is done synchronously, and there is no queuing or
      asynchronous completions at either the device or the driver level.
      
      The BTT uses 'lanes' to index into various 'on-disk' data structures,
      and lanes also act as a synchronization mechanism in case there are more
      CPUs than available lanes. We did a comparison between two lane lock
      strategies - first where we kept an atomic counter around that tracked
      which was the last lane that was used, and 'our' lane was determined by
      atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
      theoretically, no CPU would be blocked waiting for a lane. The other
      strategy was to use the cpu number we're scheduled on to and hash it to
      a lane number. Theoretically, this could block an IO that could've
      otherwise run using a different, free lane. But some fio workloads
      showed that the direct cpu -> lane hash performed faster than tracking
      'last lane' - my reasoning is the cache thrash caused by moving the
      atomic variable made that approach slower than simply waiting out the
      in-progress IO. This supports the conclusion that the driver can be a
      very simple bio-based one that does synchronous IOs instead of queuing.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      [jmoyer: fix nmi watchdog timeout in btt_map_init]
      [jmoyer: move btt initialization to module load path]
      [jmoyer: fix memory leak in the btt initialization path]
      [jmoyer: Don't overwrite corrupted arenas]
      Signed-off-by: NVishal Verma <vishal.l.verma@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      5212e11f
    • M
      dm: bump the ioctl version to 4.32.0 · 5532fba2
      Mike Snitzer 提交于
      This fix enables userspace to detect that the dm-stats changes from the
      4.2 merge are in place.
      Reported-by: NAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      5532fba2
    • M
      Revert "block, dm: don't copy bios for request clones" · 78d8e58a
      Mike Snitzer 提交于
      This reverts commit 5f1b670d.
      
      Justification for revert as reported in this dm-devel post:
      https://www.redhat.com/archives/dm-devel/2015-June/msg00160.html
      
      this change should not be pushed to mainline yet.
      
      Firstly, Christoph has a newer version of the patch that fixes silent
      data corruption problem:
        https://www.redhat.com/archives/dm-devel/2015-May/msg00229.html
      
      And the new version still depends on LLDDs to always complete requests
      to the end when error happens, while block API doesn't enforce such a
      requirement. If the assumption is ever broken, the inconsistency between
      request and bio (e.g. rq->__sector and rq->bio) will cause silent data
      corruption:
        https://www.redhat.com/archives/dm-devel/2015-June/msg00022.htmlReported-by: NJunichi Nomura <j-nomura@ce.jp.nec.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      78d8e58a
    • R
      lib/string.c: introduce strreplace() · 94df2904
      Rasmus Villemoes 提交于
      Strings are sometimes sanitized by replacing a certain character (often
      '/') by another (often '!').  In a few places, this is done the same way
      Schlemiel the Painter would do it.  Others are slightly smarter but still
      do multiple strchr() calls.  Introduce strreplace() to do this using a
      single function call and a single pass over the string.
      
      One would expect the return value to be one of three things: void, s, or
      the number of replacements made.  I chose the fourth, returning a pointer
      to the end of the string.  This is more likely to be useful (for example
      allowing the caller to avoid a strlen call).
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      94df2904
    • V
      check_syslog_permissions() cleanup · 3ea4331c
      Vasily Averin 提交于
      Patch fixes drawbacks in heck_syslog_permissions() noticed by AKPM:
      "from_file handling makes me cry.
      
      That's not a boolean - it's an enumerated value with two values
      currently defined.
      
      But the code in check_syslog_permissions() treats it as a boolean and
      also hardwires the knowledge that SYSLOG_FROM_PROC == 1 (or == `true`).
      
      And the name is wrong: it should be called from_proc to match
      SYSLOG_FROM_PROC."
      Signed-off-by: NVasily Averin <vvs@virtuozzo.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: Eric Paris <eparis@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ea4331c
    • T
      printk: implement support for extended console drivers · 6fe29354
      Tejun Heo 提交于
      printk log_buf keeps various metadata for each message including its
      sequence number and timestamp.  The metadata is currently available only
      through /dev/kmsg and stripped out before passed onto console drivers.  We
      want this metadata to be available to console drivers too so that console
      consumers can get full information including the metadata and dictionary,
      which among other things can be used to detect whether messages got lost
      in transit.
      
      This patch implements support for extended console drivers.  Consoles can
      indicate that they want extended messages by setting the new CON_EXTENDED
      flag and they'll be fed messages formatted the same way as /dev/kmsg.
      
       "<level>,<sequnum>,<timestamp>,<contflag>;<message text>\n"
      
      If extended consoles exist, in-kernel fragment assembly is disabled.  This
      ensures that all messages emitted to consoles have full metadata including
      sequence number.  The contflag carries enough information to reassemble
      the fragments from the reader side trivially.  Note that this only affects
      /dev/kmsg.  Regular console and /proc/kmsg outputs are not affected by
      this change.
      
      * Extended message formatting for console drivers is enabled iff there
        are registered extended consoles.
      
      * Comment describing /dev/kmsg message format updated to add missing
        contflag field and help distinguishing variable from verbatim terms.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Kay Sievers <kay@vrfy.org>
      Reviewed-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6fe29354
    • T
      printk: guard the amount written per line by devkmsg_read() · d43ff430
      Tejun Heo 提交于
      This patchset updates netconsole so that it can emit messages with the
      same header as used in /dev/kmsg which gives neconsole receiver full log
      information which enables things like structured logging and detection
      of lost messages.
      
      This patch (of 7):
      
      devkmsg_read() uses 8k buffer and assumes that the formatted output
      message won't overrun which seems safe given LOG_LINE_MAX, the current use
      of dict and the escaping method being used; however, we're planning to use
      devkmsg formatting wider and accounting for the buffer size properly isn't
      that complicated.
      
      This patch defines CONSOLE_EXT_LOG_MAX as 8192 and updates devkmsg_read()
      so that it limits output accordingly.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Kay Sievers <kay@vrfy.org>
      Reviewed-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d43ff430
    • J
      clone: support passing tls argument via C rather than pt_regs magic · 3033f14a
      Josh Triplett 提交于
      clone has some of the quirkiest syscall handling in the kernel, with a
      pile of special cases, historical curiosities, and architecture-specific
      calling conventions.  In particular, clone with CLONE_SETTLS accepts a
      parameter "tls" that the C entry point completely ignores and some
      assembly entry points overwrite; instead, the low-level arch-specific
      code pulls the tls parameter out of the arch-specific register captured
      as part of pt_regs on entry to the kernel.  That's a massive hack, and
      it makes the arch-specific code only work when called via the specific
      existing syscall entry points; because of this hack, any new clone-like
      system call would have to accept an identical tls argument in exactly
      the same arch-specific position, rather than providing a unified system
      call entry point across architectures.
      
      The first patch allows architectures to handle the tls argument via
      normal C parameter passing, if they opt in by selecting
      HAVE_COPY_THREAD_TLS.  The second patch makes 32-bit and 64-bit x86 opt
      into this.
      
      These two patches came out of the clone4 series, which isn't ready for
      this merge window, but these first two cleanup patches were entirely
      uncontroversial and have acks.  I'd like to go ahead and submit these
      two so that other architectures can begin building on top of this and
      opting into HAVE_COPY_THREAD_TLS.  However, I'm also happy to wait and
      send these through the next merge window (along with v3 of clone4) if
      anyone would prefer that.
      
      This patch (of 2):
      
      clone with CLONE_SETTLS accepts an argument to set the thread-local
      storage area for the new thread.  sys_clone declares an int argument
      tls_val in the appropriate point in the argument list (based on the
      various CLONE_BACKWARDS variants), but doesn't actually use or pass along
      that argument.  Instead, sys_clone calls do_fork, which calls
      copy_process, which calls the arch-specific copy_thread, and copy_thread
      pulls the corresponding syscall argument out of the pt_regs captured at
      kernel entry (knowing what argument of clone that architecture passes tls
      in).
      
      Apart from being awful and inscrutable, that also only works because only
      one code path into copy_thread can pass the CLONE_SETTLS flag, and that
      code path comes from sys_clone with its architecture-specific
      argument-passing order.  This prevents introducing a new version of the
      clone system call without propagating the same architecture-specific
      position of the tls argument.
      
      However, there's no reason to pull the argument out of pt_regs when
      sys_clone could just pass it down via C function call arguments.
      
      Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt into,
      and a new copy_thread_tls that accepts the tls parameter as an additional
      unsigned long (syscall-argument-sized) argument.  Change sys_clone's tls
      argument to an unsigned long (which does not change the ABI), and pass
      that down to copy_thread_tls.
      
      Architectures that don't opt into copy_thread_tls will continue to ignore
      the C argument to sys_clone in favor of the pt_regs captured at kernel
      entry, and thus will be unable to introduce new versions of the clone
      syscall.
      
      Patch co-authored by Josh Triplett and Thiago Macieira.
      Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
      Acked-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thiago Macieira <thiago.macieira@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3033f14a
    • J
      stddef.h: move offsetofend inside #ifndef/#endif guard, neaten · 8c7fbe57
      Joe Perches 提交于
      Commit 38764884 ("include/stddef.h: Move offsetofend() from vfio.h
      to a generic kernel header") added offsetofend outside the normal
      include #ifndef/#endif guard.  Move it inside.
      
      Miscellanea:
      
      o remove unnecessary blank line
      o standardize offsetof macros whitespace style
      Signed-off-by: NJoe Perches <joe@perches.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8c7fbe57
    • D
      compiler-intel: fix wrong compiler barrier() macro · b86a50c3
      Daniel Borkmann 提交于
      Cleanup commit 73679e50 ("compiler-intel.h: Remove duplicate
      definition") removed the double definition of __memory_barrier()
      intrinsics.
      
      However, in doing so, it also removed the preceding #undef barrier by
      accident, meaning, the actual barrier() macro from compiler-gcc.h with
      inline asm is still in place as __GNUC__ is provided.
      
      Subsequently, barrier() can never be defined as __memory_barrier() from
      compiler.h since it already has a definition in place and if we trust
      the comment in compiler-intel.h, ecc doesn't support gcc specific asm
      statements.
      
      I don't have an ecc at hand (unsure if that's still used in the field?)
      and only found this by accident during code review, a revert of that
      cleanup would be simplest option.
      
      Fixes: 73679e50 ("compiler-intel.h: Remove duplicate definition")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: NPranith Kumar <bobby.prani@gmail.com>
      Cc: Pranith Kumar <bobby.prani@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: mancha security <mancha1@zoho.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b86a50c3
    • J
      compiler-gcc: integrate the various compiler-gcc[345].h files · cb984d10
      Joe Perches 提交于
      As gcc major version numbers are going to advance rather rapidly in the
      future, there's no real value in separate files for each compiler
      version.
      
      Deduplicate some of the macros #defined in each file too.
      
      Neaten comments using normal kernel commenting style.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Segher Boessenkool <segher@kernel.crashing.org>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Alan Modra <amodra@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb984d10
    • J
      compiler-gcc.h: neatening · f6d133f8
      Joe Perches 提交于
       - Move the inline and noinline blocks together
      
       - Comment neatening
      
       - Alignment of __attribute__ uses
      
       - Consistent naming of __must_be_array macro argument
      
       - Multiline macro neatening
      Signed-off-by: NJoe Perches <joe@perches.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Segher Boessenkool <segher@kernel.crashing.org>
      Cc: Sasha Levin <levinsasha928@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Alan Modra <amodra@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f6d133f8
    • D
      zpool: remove zpool_evict() · 479305fd
      Dan Streetman 提交于
      Remove zpool_evict() helper function.  As zbud is currently the only
      zpool implementation that supports eviction, add zpool and zpool_ops
      references to struct zbud_pool and directly call zpool_ops->evict(zpool,
      handle) on eviction.
      
      Currently zpool provides the zpool_evict helper which locks the zpool
      list lock and searches through all pools to find the specific one
      matching the caller, and call the corresponding zpool_ops->evict
      function.  However, this is unnecessary, as the zbud pool can simply
      keep a reference to the zpool that created it, as well as the zpool_ops,
      and directly call the zpool_ops->evict function, when it needs to evict
      a page.  This avoids a spinlock and list search in zpool for each
      eviction.
      Signed-off-by: NDan Streetman <ddstreet@ieee.org>
      Cc: Seth Jennings <sjennings@variantweb.net>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Nitin Gupta <ngupta@vflare.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      479305fd
  3. 25 6月, 2015 20 次提交
    • D
      libnvdimm: infrastructure for btt devices · 8c2f7e86
      Dan Williams 提交于
      NVDIMM namespaces, in addition to accepting "struct bio" based requests,
      also have the capability to perform byte-aligned accesses.  By default
      only the bio/block interface is used.  However, if another driver can
      make effective use of the byte-aligned capability it can claim namespace
      interface and use the byte-aligned ->rw_bytes() interface.
      
      The BTT driver is the initial first consumer of this mechanism to allow
      adding atomic sector update semantics to a pmem or blk namespace.  This
      patch is the sysfs infrastructure to allow configuring a BTT instance
      for a namespace.  Enabling that BTT and performing i/o is in a
      subsequent patch.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      8c2f7e86
    • J
      firmware: dmi: struct dmi_header should be packed · 9ea650c8
      Jean Delvare 提交于
      Apparently the compiler does fine without it, but it feels safer and
      clearer to add the missing attribute.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      9ea650c8
    • I
      firmware: dmi_scan: add SBMIOS entry and DMI tables · d7f96f97
      Ivan Khoronzhuk 提交于
      Some utils, like dmidecode and smbios, need to access SMBIOS entry
      table area in order to get information like SMBIOS version, size, etc.
      Currently it's done via /dev/mem. But for situation when /dev/mem
      usage is disabled, the utils have to use dmi sysfs instead, which
      doesn't represent SMBIOS entry and adds code/delay redundancy when direct
      access for table is needed.
      
      So this patch creates dmi/tables and adds SMBIOS entry point to allow
      utils in question to work correctly without /dev/mem. Also patch adds
      raw dmi table to simplify dmi table processing in user space, as
      proposed by Jean Delvare.
      Tested-by: NRoy Franz <roy.franz@linaro.org>
      Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@globallogic.com>
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      d7f96f97
    • D
      drm/dp/mst: close deadlock in connector destruction. · 6b8eeca6
      Dave Airlie 提交于
      I've only seen this once, and I failed to capture the
      lockdep backtrace, but I did some investigations.
      
      If we are calling into the MST layer from EDID probing,
      we have the mode_config mutex held, if during that EDID
      probing, the MST hub goes away, then we can get a deadlock
      where the connector destruction function in the driver
      tries to retake the mode config mutex.
      
      This offloads connector destruction to a workqueue,
      and avoid the subsequenct lock ordering issue.
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6b8eeca6
    • D
      libnvdimm: blk labels and namespace instantiation · 1b40e09a
      Dan Williams 提交于
      A blk label set describes a namespace comprised of one or more
      discontiguous dpa ranges on a single dimm.  They may alias with one or
      more pmem interleave sets that include the given dimm.
      
      This is the runtime/volatile configuration infrastructure for sysfs
      manipulation of 'alt_name', 'uuid', 'size', and 'sector_size'.  A later
      patch will make these settings persistent by writing back the label(s).
      
      Unlike pmem namespaces, multiple blk namespaces can be created per
      region.  Once a blk namespace has been created a new seed device
      (unconfigured child of a parent blk region) is instantiated.  As long as
      a region has 'available_size' != 0 new child namespaces may be created.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      1b40e09a
    • D
      libnvdimm: pmem label sets and namespace instantiation. · bf9bccc1
      Dan Williams 提交于
      A complete label set is a PMEM-label per-dimm per-interleave-set where
      all the UUIDs match and the interleave set cookie matches the hosting
      interleave set.
      
      Present sysfs attributes for manipulation of a PMEM-namespace's
      'alt_name', 'uuid', and 'size' attributes.  A later patch will make
      these settings persistent by writing back the label.
      
      Note that PMEM allocations grow forwards from the start of an interleave
      set (lowest dimm-physical-address (DPA)).  BLK-namespaces that alias
      with a PMEM interleave set will grow allocations backward from the
      highest DPA.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      bf9bccc1
    • D
      libnvdimm: namespace indices: read and validate · 4a826c83
      Dan Williams 提交于
      This on media label format [1] consists of two index blocks followed by
      an array of labels.  None of these structures are ever updated in place.
      A sequence number tracks the current active index and the next one to
      write, while labels are written to free slots.
      
          +------------+
          |            |
          |  nsindex0  |
          |            |
          +------------+
          |            |
          |  nsindex1  |
          |            |
          +------------+
          |   label0   |
          +------------+
          |   label1   |
          +------------+
          |            |
           ....nslot...
          |            |
          +------------+
          |   labelN   |
          +------------+
      
      After reading valid labels, store the dpa ranges they claim into
      per-dimm resource trees.
      
      [1]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
      
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      4a826c83
    • D
      libnvdimm, nfit: add interleave-set state-tracking infrastructure · eaf96153
      Dan Williams 提交于
      On platforms that have firmware support for reading/writing per-dimm
      label space, a portion of the dimm may be accessible via an interleave
      set PMEM mapping in addition to the dimm's BLK (block-data-window
      aperture(s)) interface.  A label, stored in a "configuration data
      region" on the dimm, disambiguates which dimm addresses are accessed
      through which exclusive interface.
      
      Add infrastructure that allows the kernel to block modifications to a
      label in the set while any member dimm is active.  Note that this is
      meant only for enforcing "no modifications of active labels" via the
      coarse ioctl command.  Adding/deleting namespaces from an active
      interleave set is always possible via sysfs.
      
      Another aspect of tracking interleave sets is tracking their integrity
      when DIMMs in a set are physically re-ordered.  For this purpose we
      generate an "interleave-set cookie" that can be recorded in a label and
      validated against the current configuration.  It is the bus provider
      implementation's responsibility to calculate the interleave set cookie
      and attach it to a given region.
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      eaf96153
    • D
      libnvdimm: support for legacy (non-aliasing) nvdimms · 3d88002e
      Dan Williams 提交于
      The libnvdimm region driver is an intermediary driver that translates
      non-volatile "region"s into "namespace" sub-devices that are surfaced by
      persistent memory block-device drivers (PMEM and BLK).
      
      ACPI 6 introduces the concept that a given nvdimm may simultaneously
      offer multiple access modes to its media through direct PMEM load/store
      access, or windowed BLK mode.  Existing nvdimms mostly implement a PMEM
      interface, some offer a BLK-like mode, but never both as ACPI 6 defines.
      If an nvdimm is single interfaced, then there is no need for dimm
      metadata labels.  For these devices we can take the region boundaries
      directly to create a child namespace device (nd_namespace_io).
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3d88002e
    • D
      libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory) · 1f7df6f8
      Dan Williams 提交于
      A "region" device represents the maximum capacity of a BLK range (mmio
      block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
      volatile memory), without regard for aliasing.  Aliasing, in the
      dimm-local address space (DPA), is resolved by metadata on a dimm to
      designate which exclusive interface will access the aliased DPA ranges.
      Support for the per-dimm metadata/label arrvies is in a subsequent
      patch.
      
      The name format of "region" devices is "regionN" where, like dimms, N is
      a global ida index assigned at discovery time.  This id is not reliable
      across reboots nor in the presence of hotplug.  Look to attributes of
      the region or static id-data of the sub-namespace to generate a
      persistent name.  However, if the platform configuration does not change
      it is reasonable to expect the same region id to be assigned at the next
      boot.
      
      "region"s have 2 generic attributes "size", and "mapping"s where:
      - size: the BLK accessible capacity or the span of the
        system physical address range in the case of PMEM.
      
      - mappingN: a tuple describing a dimm's contribution to the region's
        capacity in the format (<nmemX>,<dpa>,<size>).  For a PMEM-region
        there will be at least one mapping per dimm in the interleave set.  For
        a BLK-region there is only "mapping0" listing the starting DPA of the
        BLK-region and the available DPA capacity of that space (matches "size"
        above).
      
      The max number of mappings per "region" is hard coded per the
      constraints of sysfs attribute groups.  That said the number of mappings
      per region should never exceed the maximum number of possible dimms in
      the system.  If the current number turns out to not be enough then the
      "mappings" attribute clarifies how many there are supposed to be. "32
      should be enough for anybody...".
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      1f7df6f8
    • D
      libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure · 4d88a97a
      Dan Williams 提交于
      * Implement the device-model infrastructure for loading modules and
        attaching drivers to nvdimm devices.  This is a simple association of a
        nd-device-type number with a driver that has a bitmask of supported
        device types.  To facilitate userspace bind/unbind operations 'modalias'
        and 'devtype', that also appear in the uevent, are added as generic
        sysfs attributes for all nvdimm devices.  The reason for the device-type
        number is to support sub-types within a given parent devtype, be it a
        vendor-specific sub-type or otherwise.
      
      * The first consumer of this infrastructure is the driver
        for dimm devices.  It simply uses control messages to retrieve and
        store the configuration-data image (label set) from each dimm.
      
      Note: nd_device_register() arranges for asynchronous registration of
            nvdimm bus devices by default.
      
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Neil Brown <neilb@suse.de>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      4d88a97a
    • D
      libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices · 62232e45
      Dan Williams 提交于
      Most discovery/configuration of the nvdimm-subsystem is done via sysfs
      attributes.  However, some nvdimm_bus instances, particularly the
      ACPI.NFIT bus, define a small set of messages that can be passed to the
      platform.  For convenience we derive the initial libnvdimm-ioctl command
      formats directly from the NFIT DSM Interface Example formats.
      
          ND_CMD_SMART: media health and diagnostics
          ND_CMD_GET_CONFIG_SIZE: size of the label space
          ND_CMD_GET_CONFIG_DATA: read label space
          ND_CMD_SET_CONFIG_DATA: write label space
          ND_CMD_VENDOR: vendor-specific command passthrough
          ND_CMD_ARS_CAP: report address-range-scrubbing capabilities
          ND_CMD_ARS_START: initiate scrubbing
          ND_CMD_ARS_STATUS: report on scrubbing state
          ND_CMD_SMART_THRESHOLD: configure alarm thresholds for smart events
      
      If a platform later defines different commands than this set it is
      straightforward to extend support to those formats.
      
      Most of the commands target a specific dimm.  However, the
      address-range-scrubbing commands target the bus.  The 'commands'
      attribute in sysfs of an nvdimm_bus, or nvdimm, enumerate the supported
      commands for that object.
      
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reported-by: NNicholas Moulin <nicholas.w.moulin@linux.intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      62232e45
    • D
      libnvdimm, nfit: dimm/memory-devices · e6dfb2de
      Dan Williams 提交于
      Enable nvdimm devices to be registered on a nvdimm_bus.  The kernel
      assigned device id for nvdimm devicesis dynamic.  If userspace needs a
      more static identifier it should consult a provider-specific attribute.
      In the case where NFIT is the provider, the 'nmemX/nfit/handle' or
      'nmemX/nfit/serial' attributes may be used for this purpose.
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      e6dfb2de
    • D
      libnvdimm: control character device and nvdimm_bus sysfs attributes · 45def22c
      Dan Williams 提交于
      The control device for a nvdimm_bus is registered as an "nd" class
      device.  The expectation is that there will usually only be one "nd" bus
      registered under /sys/class/nd.  However, we allow for the possibility
      of multiple buses and they will listed in discovery order as
      ndctl0...ndctlN.  This character device hosts the ioctl for passing
      control messages.  The initial command set has a 1:1 correlation with
      the commands listed in the by the "NFIT DSM Example" document [1], but
      this scheme is extensible to future command sets.
      
      Note, nd_ioctl() and the backing ->ndctl() implementation are defined in
      a subsequent patch.  This is simply the initial registrations and sysfs
      attributes.
      
      [1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      45def22c
    • D
      libnvdimm, nfit: initial libnvdimm infrastructure and NFIT support · b94d5230
      Dan Williams 提交于
      A struct nvdimm_bus is the anchor device for registering nvdimm
      resources and interfaces, for example, a character control device,
      nvdimm devices, and I/O region devices.  The ACPI NFIT (NVDIMM Firmware
      Interface Table) is one possible platform description for such
      non-volatile memory resources in a system.  The nfit.ko driver attaches
      to the "ACPI0012" device that indicates the presence of the NFIT and
      parses the table to register a struct nvdimm_bus instance.
      
      Cc: <linux-acpi@vger.kernel.org>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      b94d5230
    • L
      mm: kmemleak_alloc_percpu() should follow the gfp from per_alloc() · 8a8c35fa
      Larry Finger 提交于
      Beginning at commit d52d3997 ("ipv6: Create percpu rt6_info"), the
      following INFO splat is logged:
      
        ===============================
        [ INFO: suspicious RCU usage. ]
        4.1.0-rc7-next-20150612 #1 Not tainted
        -------------------------------
        kernel/sched/core.c:7318 Illegal context switch in RCU-bh read-side critical section!
        other info that might help us debug this:
        rcu_scheduler_active = 1, debug_locks = 0
         3 locks held by systemd/1:
         #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff815f0c8f>] rtnetlink_rcv+0x1f/0x40
         #1:  (rcu_read_lock_bh){......}, at: [<ffffffff816a34e2>] ipv6_add_addr+0x62/0x540
         #2:  (addrconf_hash_lock){+...+.}, at: [<ffffffff816a3604>] ipv6_add_addr+0x184/0x540
        stack backtrace:
        CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612 #1
        Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20   04/17/2014
        Call Trace:
          dump_stack+0x4c/0x6e
          lockdep_rcu_suspicious+0xe7/0x120
          ___might_sleep+0x1d5/0x1f0
          __might_sleep+0x4d/0x90
          kmem_cache_alloc+0x47/0x250
          create_object+0x39/0x2e0
          kmemleak_alloc_percpu+0x61/0xe0
          pcpu_alloc+0x370/0x630
      
      Additional backtrace lines are truncated.  In addition, the above splat
      is followed by several "BUG: sleeping function called from invalid
      context at mm/slub.c:1268" outputs.  As suggested by Martin KaFai Lau,
      these are the clue to the fix.  Routine kmemleak_alloc_percpu() always
      uses GFP_KERNEL for its allocations, whereas it should follow the gfp
      from its callers.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NKamalesh Babulal <kamalesh@linux.vnet.ibm.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: <stable@vger.kernel.org>	[3.18+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a8c35fa
    • D
      frontswap: allow multiple backends · d1dc6f1b
      Dan Streetman 提交于
      Change frontswap single pointer to a singly linked list of frontswap
      implementations.  Update Xen tmem implementation as register no longer
      returns anything.
      
      Frontswap only keeps track of a single implementation; any
      implementation that registers second (or later) will replace the
      previously registered implementation, and gets a pointer to the previous
      implementation that the new implementation is expected to pass all
      frontswap functions to if it can't handle the function itself.  However
      that method doesn't really make much sense, as passing that work on to
      every implementation adds unnecessary work to implementations; instead,
      frontswap should simply keep a list of all registered implementations
      and try each implementation for any function.  Most importantly, neither
      of the two currently existing frontswap implementations in the kernel
      actually do anything with any previous frontswap implementation that
      they replace when registering.
      
      This allows frontswap to successfully manage multiple implementations by
      keeping a list of them all.
      Signed-off-by: NDan Streetman <ddstreet@ieee.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d1dc6f1b
    • T
      x86, mirror: x86 enabling - find mirrored memory ranges · b05b9f5f
      Tony Luck 提交于
      UEFI GetMemoryMap() uses a new attribute bit to mark mirrored memory
      address ranges.  See UEFI 2.5 spec pages 157-158:
      
        http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf
      
      On EFI enabled systems scan the memory map and tell memblock about any
      mirrored ranges.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Xiexiuqi <xiexiuqi@huawei.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b05b9f5f
    • T
      mm/memblock: allocate boot time data structures from mirrored memory · a3f5bafc
      Tony Luck 提交于
      Try to allocate all boot time kernel data structures from mirrored
      memory.
      
      If we run out of mirrored memory print warnings, but fall back to using
      non-mirrored memory to make sure that we still boot.
      
      By number of bytes, most of what we allocate at boot time is the page
      structures.  64 bytes per 4K page on x86_64 ...  or about 1.5% of total
      system memory.  For workloads where the bulk of memory is allocated to
      applications this may represent a useful improvement to system
      availability since 1.5% of total memory might be a third of the memory
      allocated to the kernel.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Xiexiuqi <xiexiuqi@huawei.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a3f5bafc
    • T
      mm/memblock: add extra "flags" to memblock to allow selection of memory based on attribute · fc6daaf9
      Tony Luck 提交于
      Some high end Intel Xeon systems report uncorrectable memory errors as a
      recoverable machine check.  Linux has included code for some time to
      process these and just signal the affected processes (or even recover
      completely if the error was in a read only page that can be replaced by
      reading from disk).
      
      But we have no recovery path for errors encountered during kernel code
      execution.  Except for some very specific cases were are unlikely to ever
      be able to recover.
      
      Enter memory mirroring. Actually 3rd generation of memory mirroing.
      
      Gen1: All memory is mirrored
      	Pro: No s/w enabling - h/w just gets good data from other side of the
      	     mirror
      	Con: Halves effective memory capacity available to OS/applications
      
      Gen2: Partial memory mirror - just mirror memory begind some memory controllers
      	Pro: Keep more of the capacity
      	Con: Nightmare to enable. Have to choose between allocating from
      	     mirrored memory for safety vs. NUMA local memory for performance
      
      Gen3: Address range partial memory mirror - some mirror on each memory
            controller
      	Pro: Can tune the amount of mirror and keep NUMA performance
      	Con: I have to write memory management code to implement
      
      The current plan is just to use mirrored memory for kernel allocations.
      This has been broken into two phases:
      
      1) This patch series - find the mirrored memory, use it for boot time
         allocations
      
      2) Wade into mm/page_alloc.c and define a ZONE_MIRROR to pick up the
         unused mirrored memory from mm/memblock.c and only give it out to
         select kernel allocations (this is still being scoped because
         page_alloc.c is scary).
      
      This patch (of 3):
      
      Add extra "flags" to memblock to allow selection of memory based on
      attribute.  No functional changes
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Xiexiuqi <xiexiuqi@huawei.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fc6daaf9