linux-toradex.git, branch v4.4.84

Linux 4.4.84

2017-08-25T00:02:58+00:00

usb: qmi_wwan: add D-Link DWM-222 device ID

2017-08-25T00:02:36+00:00

commit bed9ff165960921303a100228585f2d1691b42eb upstream.

Signed-off-by: Hector Martin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usb: optimize acpi companion search for usb port devices

2017-08-25T00:02:36+00:00

commit ed18c5fa945768a9bec994e786edbbbc7695acf6 upstream.

This optimization significantly reduces xhci driver load time.

In ACPI tables the acpi companion port devices are children of
the hub device. The port devices are identified by their port number
returned by the ACPI _ADR method.
_ADR 0 is reserved for the root hub device.

The current implementation to find a acpi companion port device
loops through all acpi port devices under that parent hub, evaluating
their _ADR method each time a new port device is added.

for a xHC controller with 25 ports under its roothub it
will end up invoking ACPI bytecode 625 times before all ports
are ready, making it really slow.

The _ADR values are already read and cached earler. So instead of
running the bytecode again we can check the cached _ADR value first,
and then fall back to the old way.

As one of the more significant changes, the xhci load time on
Intel kabylake reduced by 70%, (28ms) from
initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs
to
initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs

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

perf/x86: Fix LBR related crashes on Intel Atom

2017-08-25T00:02:36+00:00

commit 6fc2e83077b05a061afe9b24f2fdff7a0434eb67 upstream.

This patches fixes the LBR kernel crashes on Intel Atom.

The kernel was assuming that if the CPU supports 64-bit format
LBR, then it has an LBR_SELECT MSR. Atom uses 64-bit LBR format
but does not have LBR_SELECT. That was causing NULL pointer
dereferences in a couple of places.

Signed-off-by: Stephane Eranian 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: kan.liang@intel.com
Fixes: 96f3eda67fcf ("perf/x86/intel: Fix static checker warning in lbr enable")
Link: http://lkml.kernel.org/r/1449182000-31524-2-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Denys Zagorui 
Signed-off-by: Greg Kroah-Hartman

pids: make task_tgid_nr_ns() safe

2017-08-25T00:02:36+00:00

commit dd1c1f2f2028a7b851f701fc6a8ebe39dcb95e7c upstream.

This was reported many times, and this was even mentioned in commit
52ee2dfdd4f5 ("pids: refactor vnr/nr_ns helpers to make them safe") but
somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns() is
not safe because task->group_leader points to nowhere after the exiting
task passes exit_notify(), rcu_read_lock() can not help.

We really need to change __unhash_process() to nullify group_leader,
parent, and real_parent, but this needs some cleanups.  Until then we
can turn task_tgid_nr_ns() into another user of __task_pid_nr_ns() and
fix the problem.

Reported-by: Troy Kensinger 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Sanitize 'move_pages()' permission checks

2017-08-25T00:02:36+00:00

commit 197e7e521384a23b9e585178f3f11c9fa08274b9 upstream.

The 'move_paghes()' system call was introduced long long ago with the
same permission checks as for sending a signal (except using
CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).

That turns out to not be a great choice - while the system call really
only moves physical page allocations around (and you need other
capabilities to do a lot of it), you can check the return value to map
out some the virtual address choices and defeat ASLR of a binary that
still shares your uid.

So change the access checks to the more common 'ptrace_may_access()'
model instead.

This tightens the access checks for the uid, and also effectively
changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that
anybody really _uses_ this legacy system call any more (we hav ebetter
NUMA placement models these days), so I expect nobody to notice.

Famous last words.

Reported-by: Otto Ebeling 
Acked-by: Eric W. Biederman 
Cc: Willy Tarreau 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()

2017-08-25T00:02:36+00:00

commit 277867ade8262583f4280cadbe90e0031a3706a7 upstream.

of_find_compatible_node() is calling of_node_put() on its first argument
thus leading to an unbalanced of_node_get/put() issue if the node has not
been retained before that.

Instead of passing the root node, pass NULL, which does exactly the same:
iterate over all DT nodes, starting from the root node.

Signed-off-by: Boris Brezillon 
Reported-by: Alexandre Belloni 
Fixes: 3d61467f9bab ("irqchip: atmel-aic: Implement RTC irq fixup")
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()

2017-08-25T00:02:36+00:00

commit 469bcef53c546bb792aa66303933272991b7831d upstream.

aic_common_irq_fixup() is calling twice of_node_put() on the same node
thus leading to an unbalanced refcount on the root node.

Signed-off-by: Boris Brezillon 
Reported-by: Alexandre Belloni 
Fixes: b2f579b58e93 ("irqchip: atmel-aic: Add irq fixup infrastructure")
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

x86/asm/64: Clear AC on NMI entries

2017-08-25T00:02:36+00:00

commit e93c17301ac55321fc18e0f8316e924e58a83c8c upstream.

This closes a hole in our SMAP implementation.

This patch comes from grsecurity. Good catch!

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/314cc9f294e8f14ed85485727556ad4f15bb1659.1502159503.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xen: fix bio vec merging

2017-08-25T00:02:36+00:00

commit 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.

The current test for bio vec merging is not fully accurate and can be
tricked into merging bios when certain grant combinations are used.
The result of these malicious bio merges is a bio that extends past
the memory page used by any of the originating bios.

Take into account the following scenario, where a guest creates two
grant references that point to the same mfn, ie: grant 1 -> mfn A,
grant 2 -> mfn A.

These references are then used in a PV block request, and mapped by
the backend domain, thus obtaining two different pfns that point to
the same mfn, pfn B -> mfn A, pfn C -> mfn A.

If those grants happen to be used in two consecutive sectors of a disk
IO operation becoming two different bios in the backend domain, the
checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
(they both point to the same mfn). However due to the bio merging,
the backend domain will end up with a bio that expands past mfn A into
mfn A + 1.

Fix this by making sure the check in xen_biovec_phys_mergeable takes
into account the offset and the length of the bio, this basically
replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
addresses). While there also remove the usage of
__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
of xen_biovec_phys_mergeable.

Reported-by: "Jan H. Schönherr" 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Juergen Gross 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman