linux-toradex.git/drivers, branch v4.9.85

libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment

2018-02-28T09:18:34+00:00

commit 41fce90f26333c4fa82e8e43b9ace86c4e8a0120 upstream.

The following namespace configuration attempt:

    # ndctl create-namespace -e namespace0.0 -m devdax -a 1G -f
    libndctl: ndctl_dax_enable: dax0.1: failed to enable
      Error: namespace0.0: failed to enable

    failed to reconfigure namespace: No such device or address

...fails when the backing memory range is not physically aligned to 1G:

    # cat /proc/iomem | grep Persistent
    210000000-30fffffff : Persistent Memory (legacy)

In the above example the 4G persistent memory range starts and ends on a
256MB boundary.

We handle this case correctly when needing to handle cases that violate
section alignment (128MB) collisions against "System RAM", and we simply
need to extend that padding/truncation for the 1GB alignment use case.

Cc: 
Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute...")
Reported-and-tested-by: Jane Chu 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

IB/core: disable memory registration of filesystem-dax vmas

2018-02-28T09:18:34+00:00

commit 5f1d43de54164dcfb9bfa542fcc92c1e1a1b6c1d upstream.

Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow RDMA to create long standing memory registrations
against filesytem-dax vmas.

Link: http://lkml.kernel.org/r/151068941011.7446.7766030590347262502.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams 
Reported-by: Christoph Hellwig 
Reviewed-by: Christoph Hellwig 
Acked-by: Jason Gunthorpe 
Acked-by: Doug Ledford 
Cc: Sean Hefty 
Cc: Hal Rosenstock 
Cc: Jeff Moyer 
Cc: Ross Zwisler 
Cc: Inki Dae 
Cc: Jan Kara 
Cc: Joonyoung Shim 
Cc: Kyungmin Park 
Cc: Mauro Carvalho Chehab 
Cc: Mel Gorman 
Cc: Seung-Woo Kim 
Cc: Vlastimil Babka 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

v4l2: disable filesystem-dax mapping support

2018-02-28T09:18:33+00:00

commit b70131de648c2b997d22f4653934438013f407a1 upstream.

V4L2 memory registrations are incompatible with filesystem-dax that
needs the ability to revoke dma access to a mapping at will, or
otherwise allow the kernel to wait for completion of DMA.  The
filesystem-dax implementation breaks the traditional solution of
truncate of active file backed mappings since there is no page-cache
page we can orphan to sustain ongoing DMA.

If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.

Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: Dan Williams 
Reported-by: Jan Kara 
Reviewed-by: Jan Kara 
Cc: Mauro Carvalho Chehab 
Cc: Christoph Hellwig 
Cc: Doug Ledford 
Cc: Hal Rosenstock 
Cc: Inki Dae 
Cc: Jason Gunthorpe 
Cc: Jeff Moyer 
Cc: Joonyoung Shim 
Cc: Kyungmin Park 
Cc: Mel Gorman 
Cc: Ross Zwisler 
Cc: Sean Hefty 
Cc: Seung-Woo Kim 
Cc: Vlastimil Babka 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

device-dax: implement ->split() to catch invalid munmap attempts

2018-02-28T09:18:33+00:00

commit 9702cffdbf2129516db679e4467db81e1cd287da upstream.

Similar to how device-dax enforces that the 'address', 'offset', and
'len' parameters to mmap() be aligned to the device's fundamental
alignment, the same constraints apply to munmap().  Implement ->split()
to fail munmap calls that violate the alignment constraint.

Otherwise, we later fail VM_BUG_ON checks in the unmap_page_range() path
with crash signatures of the form:

    vma ffff8800b60c8a88 start 00007f88c0000000 end 00007f88c0e00000
    next           (null) prev           (null) mm ffff8800b61150c0
    prot 8000000000000027 anon_vma           (null) vm_ops ffffffffa0091240
    pgoff 0 file ffff8800b638ef80 private_data           (null)
    flags: 0x380000fb(read|write|shared|mayread|maywrite|mayexec|mayshare|softdirty|mixedmap|hugepage)
    ------------[ cut here ]------------
    kernel BUG at mm/huge_memory.c:2014!
    [..]
    RIP: 0010:__split_huge_pud+0x12a/0x180
    [..]
    Call Trace:
     unmap_page_range+0x245/0xa40
     ? __vma_adjust+0x301/0x990
     unmap_vmas+0x4c/0xa0
     unmap_region+0xae/0x120
     ? __vma_rb_erase+0x11a/0x230
     do_munmap+0x276/0x410
     vm_munmap+0x6a/0xa0
     SyS_munmap+0x1d/0x30

Link: http://lkml.kernel.org/r/151130418681.4029.7118245855057952010.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams 
Reported-by: Jeff Moyer 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

libnvdimm: fix integer overflow static analysis warning

2018-02-28T09:18:33+00:00

commit 58738c495e15badd2015e19ff41f1f1ed55200bc upstream.

Dan reports:
    The patch 62232e45f4a2: "libnvdimm: control (ioctl) messages for
    nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the
    following static checker warning:

            drivers/nvdimm/bus.c:1018 __nd_ioctl()
            warn: integer overflows 'buf_len'

    From a casual review, this seems like it might be a real bug.  On
    the first iteration we load some data into in_env[].  On the second
    iteration we read a use controlled "in_size" from nd_cmd_in_size().
    It can go up to UINT_MAX - 1.  A high number means we will fill the
    whole in_env[] buffer.  But we potentially keep looping and adding
    more to in_len so now it can be any value.

    It simple enough to change, but it feels weird that we keep looping
    even though in_env is totally full.  Shouldn't we just return an
    error if we don't have space for desc->in_num.

We keep looping because the size of the total input is allowed to be
bigger than the 'envelope' which is a subset of the payload that tells
us how much data to expect. For safety explicitly check that buf_len
does not overflow which is what the checker flagged.

Cc: 
Fixes: 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus..."
Reported-by: Dan Carpenter 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

binder: add missing binder_unlock()

2018-02-28T09:18:33+00:00

When commit 4be5a2810489 ("binder: check for binder_thread allocation
failure in binder_poll()") was applied to 4.4-stable and 4.9-stable it
was forgotten to release the global binder lock in the new error path.
The global binder lock wasn't removed until v4.14, by commit
a60b890f607d ("binder: remove global binder lock").

Fix the new error path to release the lock.

Reported-by: Guenter Roeck 
Signed-off-by: Eric Biggers 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: add new device to use atpx quirk

2018-02-28T09:18:33+00:00

commit 6e59de2048eb375a9bfcd39461ef841cd2a78962 upstream.

The affected system (0x0813) is pretty similar to another one (0x0812),
it also needs to use ATPX power control.

Signed-off-by: Kai-Heng Feng 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)

2018-02-28T09:18:32+00:00

commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream.

We only support vga_switcheroo and runtime pm on PX/HG systems
so forcing runpm to 1 doesn't do anything useful anyway.

Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
that the cleanup path is correct as well.  This mirrors what
radeon does as well.

v2: rework the patch originally sent by Lukas (Alex)

Acked-by: Lukas Wunner 
Reported-by: Lukas Wunner 
Signed-off-by: Alex Deucher 
Signed-off-by: Lukas Wunner  (v1)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: add atpx quirk handling (v2)

2018-02-28T09:18:32+00:00

commit 052c299080cd6859f82a8154a7a673fafabe644c upstream.

Add quirks for handling PX/HG systems.  In this case, add
a quirk for a weston dGPU that only seems to properly power
down using ATPX power control rather than HG (_PR3).

v2: append a new weston XT

Signed-off-by: Alex Deucher 
Signed-off-by: Junwei Zhang  (v2)
Reviewed-and-Tested-by: Junwei Zhang 
Reviewed-by: Alex Deucher 
Acked-by: Christian König 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Add dpm quirk for Jet PRO (v2)

2018-02-28T09:18:32+00:00

commit f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 upstream.

Fixes stability issues.

v2: clamp sclk to 600 Mhz

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370
Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman