linux-stable.git/drivers, branch v4.4.3

intel_scu_ipcutil: underflow in scu_reg_access()

2016-02-25T20:01:23+00:00

commit b1d353ad3d5835b16724653b33c05124e1b5acf1 upstream.

"count" is controlled by the user and it can be negative.  Let's prevent
that by making it unsigned.  You have to have CAP_SYS_RAWIO to call this
function so the bug is not as serious as it could be.

Fixes: 5369c02d951a ('intel_scu_ipc: Utility driver for intel scu ipc')
Signed-off-by: Dan Carpenter 
Signed-off-by: Darren Hart 
Signed-off-by: Greg Kroah-Hartman

drivers/hwspinlock: fix race between radix tree insertion and lookup

2016-02-25T20:01:23+00:00

commit c6400ba7e13a41539342f1b6e1f9e78419cb0148 upstream.

of_hwspin_lock_get_id() is protected by the RCU lock, which means that
insertions can occur simultaneously with the lookup.  If the radix tree
transitions from a height of 0, we can see a slot with the indirect_ptr
bit set, which will cause us to at least read random memory, and could
cause other havoc.

Fix this by using the newly introduced radix_tree_iter_retry().

Signed-off-by: Matthew Wilcox 
Cc: Hugh Dickins 
Cc: Ohad Ben-Cohen 
Cc: Konstantin Khlebnikov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xhci: Fix list corruption in urb dequeue at host removal

2016-02-25T20:01:22+00:00

commit 5c82171167adb8e4ac77b91a42cd49fb211a81a0 upstream.

xhci driver frees data for all devices, both usb2 and and usb3 the
first time usb_remove_hcd() is called, including td_list and and xhci_ring
structures.

When usb_remove_hcd() is called a second time for the second xhci bus it
will try to dequeue all pending urbs, and touches td_list which is already
freed for that endpoint.

Reported-by: Joe Lawrence 
Tested-by: Joe Lawrence 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

Revert "xhci: don't finish a TD if we get a short-transfer event mid TD"

2016-02-25T20:01:22+00:00

commit a6835090716a85f2297668ba593bd00e1051e662 upstream.

This reverts commit e210c422b6fd ("xhci: don't finish a TD if we get a
short transfer event mid TD")

Turns out that most host controllers do not follow the xHCI specs and never
send the second event for the last TRB in the TD if there was a short event
mid-TD.

Returning the URB directly after the first short-transfer event is far
better than never returning the URB. (class drivers usually timeout
after 30sec). For the hosts that do send the second event we will go
back to treating it as misplaced event and print an error message for it.

The origial patch was sent to stable kernels and needs to be reverted from
there as well

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts

2016-02-25T20:01:22+00:00

commit 46924008273ed03bd11dbb32136e3da4cfe056e1 upstream.

According to the VT-d specification we need to clear the PPR bit in
the Page Request Status register when handling page requests, or the
hardware won't generate any more interrupts.

This wasn't actually necessary on SKL/KBL (which may well be the
subject of a hardware erratum, although it's harmless enough). But
other implementations do appear to get it right, and we only ever get
one interrupt unless we clear the PPR bit.

Reported-by: CQ Tang 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG

2016-02-25T20:01:22+00:00

commit fda3bec12d0979aae3f02ee645913d66fbc8a26e upstream.

This is a 32-bit register. Apparently harmless on real hardware, but
causing justified warnings in simulation.

Signed-off-by: CQ Tang 
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users

2016-02-25T20:01:21+00:00

commit e57e58bd390a6843db58560bf7b8341665d2e058 upstream.

Holding mm_users works OK for graphics, which was the first user of SVM
with VT-d. However, it works less well for other devices, where we actually
do a mmap() from the file descriptor to which the SVM PASID state is tied.

In this case on process exit we end up with a recursive reference count:
 - The MM remains alive until the file is closed and the driver's release()
   call ends up unbinding the PASID.
 - The VMA corresponding to the mmap() remains intact until the MM is
   destroyed.
 - Thus the file isn't closed, even when exit_files() runs, because the
   VMA is still holding a reference to it. And the MM remains alive…

To address this issue, we *stop* holding mm_users while the PASID is bound.
We already hold mm_count by virtue of the MMU notifier, and that can be
made to be sufficient.

It means that for a period during process exit, the fun part of mmput()
has happened and exit_mmap() has been called so the MM is basically
defunct. But the PGD still exists and the PASID is still bound to it.

During this period, we have to be very careful — exit_mmap() doesn't use
mm->mmap_sem because it doesn't expect anyone else to be touching the MM
(quite reasonably, since mm_users is zero). So we also need to fix the
fault handler to just report failure if mm_users is already zero, and to
temporarily bump mm_users while handling any faults.

Additionally, exit_mmap() calls mmu_notifier_release() *before* it tears
down the page tables, which is too early for us to flush the IOTLB for
this PASID. And __mmu_notifier_release() removes every notifier from the
list, so when exit_mmap() finally *does* tear down the mappings and
clear the page tables, we don't get notified. So we work around this by
clearing the PASID table entry in our MMU notifier release() callback.
That way, the hardware *can't* get any pages back from the page tables
before they get cleared.

Hardware designers have confirmed that the resulting 'PASID not present'
faults should be handled just as gracefully as 'page not present' faults,
the important criterion being that they don't perturb the operation for
any *other* PASID in the system.

Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Correct the wrong setting of alias DTE in do_attach

2016-02-25T20:01:21+00:00

commit 9b1a12d29109234d2b9718d04d4d404b7da4e794 upstream.

In below commit alias DTE is set when its peripheral is
setting DTE. However there's a code bug here to wrongly
set the alias DTE, correct it in this patch.

commit e25bfb56ea7f046b71414e02f80f620deb5c6362
Author: Joerg Roedel 
Date:   Tue Oct 20 17:33:38 2015 +0200

    iommu/amd: Set alias DTE in do_attach/do_detach

Signed-off-by: Baoquan He 
Tested-by: Mark Hounschell 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: Don't skip PCI devices when disabling IOTLB

2016-02-25T20:01:21+00:00

commit da972fb13bc5a1baad450c11f9182e4cd0a091f6 upstream.

Fix a simple typo when disabling IOTLB on PCI(e) devices.

Fixes: b16d0cb9e2fc ("iommu/vt-d: Always enable PASID/PRI PCI capabilities before ATS")
Signed-off-by: Jeremy McNicoll 
Reviewed-by: Alex Williamson 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

Input: vmmouse - fix absolute device registration

2016-02-25T20:01:21+00:00

commit d4f1b06d685d11ebdaccf11c0db1cb3c78736862 upstream.

We should set device's capabilities first, and then register it,
otherwise various handlers already present in the kernel will not be
able to connect to the device.

Reported-by: Lauri Kasanen 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman