linux-stable.git/drivers/dax, branch linux-4.8.y

device-dax: fix private mapping restriction, permit read-only

2016-12-15T16:50:34+00:00

commit 325896ffdf90f7cbd59fb873b7ba20d60d1ddf3c upstream.

Hugh notes in response to commit 4cb19355ea19 "device-dax: fail all
private mapping attempts":

  "I think that is more restrictive than you intended: haven't tried, but I
  believe it rejects a PROT_READ, MAP_SHARED, O_RDONLY fd mmap, leaving no
  way to mmap /dev/dax without write permission to it."

Indeed it does restrict read-only mappings, switch to checking
VM_MAYSHARE, not VM_SHARED.

Cc: Dave Hansen 
Cc: Pawel Lebioda 
Fixes: 4cb19355ea19 ("device-dax: fail all private mapping attempts")
Reported-by: Hugh Dickins 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

device-dax: fail all private mapping attempts

2016-12-02T08:10:33+00:00

commit 4cb19355ea19995941ccaad115dbfac6b75215ca upstream.

The device-dax implementation originally tried to be tricky and allow
private read-only mappings, but in the process allowed writable
MAP_PRIVATE + MAP_NORESERVE mappings.  For simplicity and predictability
just fail all private mapping attempts since device-dax memory is
statically allocated and will never support overcommit.

Cc: Dave Hansen 
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Reported-by: Pawel Lebioda 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

device-dax: check devm_nsio_enable() return value

2016-12-02T08:10:33+00:00

commit 6a84fb4b4e439a8ef0ce19ec7e7661ad76f655c9 upstream.

If the dax_pmem driver is passed a resource that is already busy the
driver probe attempt should fail with a message like the following:

  dax_pmem dax0.1: could not reserve region [mem 0x100000000-0x11fffffff]

However, if we do not catch the error we crash for the obvious reason of
accessing memory that is not mapped.

 BUG: unable to handle kernel paging request at ffffc90020001000
 IP: [] __memcpy+0x12/0x20
 [..]
 Call Trace:
  [] ? nsio_rw_bytes+0x60/0x180
  [] nd_pfn_validate+0x75/0x320
  [] nvdimm_setup_pfn+0xb9/0x5d0
  [] ? devm_nsio_enable+0xff/0x110
  [] dax_pmem_probe+0x59/0x260

Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Reported-by: Dave Hansen 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

device-dax: fix percpu_ref_exit ordering

2016-11-10T15:38:47+00:00

commit 52e73eb2872c9af6f382b2b22954ca8214397a4e upstream.

We need to wait until the percpu_ref is released before exit. Otherwise,
we sometimes lose the race and trigger this new warning that was added
in v4.9 (commit a67823c1ed10 "percpu-refcount: init ->confirm_switch
member properly"):

 WARNING: CPU: 0 PID: 3629 at lib/percpu-refcount.c:107 percpu_ref_exit+0x51/0x60
 [..]
 Call Trace:
  [] dump_stack+0x85/0xc2
  [] __warn+0xcb/0xf0
  [] warn_slowpath_null+0x1d/0x20
  [] percpu_ref_exit+0x51/0x60
  [] dax_pmem_percpu_exit+0x1a/0x50 [dax_pmem]
  [] devm_action_release+0xf/0x20

Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

dax: fix mapping size check

2016-09-03T17:40:57+00:00

pgoff_to_phys() validates that both the starting address and the length
of the mapping against the resource list.  We need to check for a
mapping size of PMD_SIZE not PAGE_SIZE in the pmd fault path.

Signed-off-by: Dan Williams

dax: fix device-dax region base

2016-08-27T00:39:35+00:00

The data offset for a dax region needs to account for a reservation in
the resource range.  Otherwise, device-dax is allowing mappings directly
into the memmap or device-info-block area with crash signatures like the
following:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
 IP: get_zone_device_page+0x11/0x30
 Call Trace:
   follow_devmap_pmd+0x298/0x2c0
   follow_page_mask+0x275/0x530
   __get_user_pages+0xe3/0x750
   __gfn_to_pfn_memslot+0x1b2/0x450 [kvm]
   tdp_page_fault+0x130/0x280 [kvm]
   kvm_mmu_page_fault+0x5f/0xf0 [kvm]
   handle_ept_violation+0x94/0x180 [kvm_intel]
   vmx_handle_exit+0x1d3/0x1440 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0x81d/0x16a0 [kvm]
   kvm_vcpu_ioctl+0x33c/0x620 [kvm]
   do_vfs_ioctl+0xa2/0x5d0
   SyS_ioctl+0x79/0x90
   entry_SYSCALL_64_fastpath+0x1a/0xa4

Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory")
Link: http://lkml.kernel.org/r/147205536732.1606.8994275381938837346.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams 
Reported-by: Abhilash Kumar Mulumudi 
Reported-by: Toshi Kani 
Tested-by: Toshi Kani 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dax: use devm_add_action_or_reset()

2016-07-06T22:14:48+00:00

If devm_add_action() fails, we are explicitly calling the cleanup to free
the resources allocated. Use the helper devm_add_action_or_reset()
and return directly in case of error, since the cleanup function
has been already called by the helper if there was any error.

Reported-by: Sudip Mukherjee 
Signed-off-by: Vikas C Sajjan 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Dan Williams

/dev/dax, core: file operations and dax-mmap

2016-05-21T05:02:55+00:00

The "Device DAX" core enables dax mappings of performance / feature
differentiated memory.  An open mapping or file handle keeps the backing
struct device live, but new mappings are only possible while the device
is enabled.   Faults are handled under rcu_read_lock to synchronize
with the enabled state of the device.

Similar to the filesystem-dax case the backing memory may optionally
have struct page entries.  However, unlike fs-dax there is no support
for private mappings, or mappings that are not backed by media (see
use of zero-page in fs-dax).

Mappings are always guaranteed to match the alignment of the dax_region.
If the dax_region is configured to have a 2MB alignment, all mappings
are guaranteed to be backed by a pmd entry.  Contrast this determinism
with the fs-dax case where pmd mappings are opportunistic.  If userspace
attempts to force a misaligned mapping, the driver will fail the mmap
attempt.  See dax_dev_check_vma() for other scenarios that are rejected,
like MAP_PRIVATE mappings.

Cc: Hannes Reinecke 
Cc: Jeff Moyer 
Cc: Christoph Hellwig 
Cc: Andrew Morton 
Cc: Dave Hansen 
Cc: Ross Zwisler 
Acked-by: "Paul E. McKenney" 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Dan Williams

/dev/dax, pmem: direct access to persistent memory

2016-05-21T05:02:53+00:00

Device DAX is the device-centric analogue of Filesystem DAX
(CONFIG_FS_DAX).  It allows memory ranges to be allocated and mapped
without need of an intervening file system.  Device DAX is strict,
precise and predictable.  Specifically this interface:

1/ Guarantees fault granularity with respect to a given page size (pte,
pmd, or pud) set at configuration time.

2/ Enforces deterministic behavior by being strict about what fault
scenarios are supported.

For example, by forcing MADV_DONTFORK semantics and omitting MAP_PRIVATE
support device-dax guarantees that a mapping always behaves/performs the
same once established.  It is the "what you see is what you get" access
mechanism to differentiated memory vs filesystem DAX which has
filesystem specific implementation semantics.

Persistent memory is the first target, but the mechanism is also
targeted for exclusive allocations of performance differentiated memory
ranges.

This commit is limited to the base device driver infrastructure to
associate a dax device with pmem range.

Cc: Jeff Moyer 
Cc: Christoph Hellwig 
Cc: Andrew Morton 
Cc: Dave Hansen 
Cc: Ross Zwisler 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Dan Williams