linux-toradex.git, branch v4.2.6

Linux 4.2.6

2015-11-09T22:37:56+00:00

xen: fix backport of previous kexec patch

2015-11-09T22:37:40+00:00

Fixes the backport of 0b34a166f291d255755be46e43ed5497cdd194f2 upstream

Commit 0b34a166f291d255755be46e43ed5497cdd194f2 "x86/xen: Support
kexec/kdump in HVM guests by doing a soft reset" has been added to the
4.2-stable tree" needed to correct the CONFIG variable, as
CONFIG_KEXEC_CORE only showed up in 4.3.

Reported-by: David Vrabel 
Reported-by: Luis Henriques 
Signed-off-by: Greg Kroah-Hartman

pinctrl: baytrail: Use raw_spinlock for locking

2015-11-09T22:37:40+00:00

commit 78e1c896932df5b8bcdff7bf5417d8e72a4d0d6b upstream.

The Intel Baytrail pinctrl driver implements irqchip callbacks which are
called with desc->lock raw_spinlock held. In mainline this is fine because
spinlock resolves to raw_spinlock. However, running the same code in -rt we
get:

 BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
 Preemption disabled at:[] cpu_startup_entry+0x17f/0x480

 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #13
  ...
 Call Trace:
    [] dump_stack+0x4a/0x61
  [] ___might_sleep+0xe7/0x170
  [] rt_spin_lock+0x1f/0x50
  [] byt_gpio_clear_triggering+0x38/0x60
  [] byt_irq_mask+0x11/0x20
  [] handle_level_irq+0x83/0x150
  [] generic_handle_irq+0x27/0x40
  [] byt_gpio_irq_handler+0x7f/0xc0
  [] handle_irq+0xaa/0x190
  ...

This is because in -rt spinlocks are preemptible so taking the driver
private spinlock in irqchip callbacks causes might_sleep() to trigger.

In order to keep -rt happy but at the same time make sure that register
accesses get serialized, convert the driver to use raw_spinlock instead.

Also shorten the critical section a bit in few places.

Suggested-by: Linus Walleij 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Cc: Lucas De Marchi 
Signed-off-by: Greg Kroah-Hartman

pinctrl: baytrail: Serialize all register access

2015-11-09T22:37:40+00:00

commit 39ce8150a079e3ae6ed9abf26d7918a558ef7c19 upstream.

There is a hardware issue in Intel Baytrail where concurrent GPIO register
access might result reads of 0xffffffff and writes might get dropped
completely.

Prevent this from happening by taking the serializing lock in all places
where it is possible that more than one thread might be accessing the
hardware concurrently.

Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Cc: Lucas De Marchi 
Signed-off-by: Greg Kroah-Hartman

thp: use is_zero_pfn() only after pte_present() check

2015-11-09T22:37:39+00:00

commit 47aee4d8e314384807e98b67ade07f6da476aa75 upstream.

Use is_zero_pfn() on pteval only after pte_present() check on pteval
(It might be better idea to introduce is_zero_pte() which checks
pte_present() first).

Otherwise when working on a swap or migration entry and if pte_pfn's
result is equal to zero_pfn by chance, we lose user's data in
__collapse_huge_page_copy().  So if you're unlucky, the application
segfaults and finally you could see below message on exit:

BUG: Bad rss-counter state mm:ffff88007f099300 idx:2 val:3

Fixes: ca0984caa823 ("mm: incorporate zero pages into transparent huge pages")
Signed-off-by: Minchan Kim 
Reviewed-by: Andrea Arcangeli 
Acked-by: Kirill A. Shutemov 
Cc: Mel Gorman 
Acked-by: Vlastimil Babka 
Cc: Hugh Dickins 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix up user_dmabuf refcounting

2015-11-09T22:37:39+00:00

commit 54c12bc374408faddbff75dbf1a6167c19af39c4 upstream.

If user space calls unreference on a user_dmabuf it will typically
kill the struct ttm_base_object member which is responsible for the
user-space visibility. However the dmabuf part may still be alive and
refcounted. In some situations, like for shared guest-backed surface
referencing/opening, the driver may try to reference the
struct ttm_base_object member again, causing an immediate kernel warning
and a later kernel NULL pointer dereference.

Fix this by always maintaining a reference on the struct
ttm_base_object member, in situations where it might subsequently be
referenced.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

NVMe: Fix memory leak on retried commands

2015-11-09T22:37:39+00:00

commit 0dfc70c33409afc232ef0b9ec210535dfbf9bc61 upstream.

Resources are reallocated for requeued commands, so unmap and release
the iod for the failed command.

It's a pretty bad memory leak and causes a kernel hang if you remove a
drive because of a busy dma pool. You'll get messages spewing like this:

  nvme 0000:xx:xx.x: dma_pool_destroy prp list 256, ffff880420dec000 busy

and lock up pci and the driver since removal never completes while
holding a lock.

Signed-off-by: Keith Busch 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

arm64: compat: fix stxr failure case in SWP emulation

2015-11-09T22:37:39+00:00

commit 589cb22bbedacf325951014c07a35a2b01ca57f6 upstream.

If the STXR instruction fails in the SWP emulation code, we leave *data
overwritten with the loaded value, therefore corrupting the data written
by a subsequent, successful attempt.

This patch re-jigs the code so that we only write back to *data once we
know that the update has happened.

Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reported-by: Shengjiu Wang 
Reported-by: Vladimir Murzin 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

cpufreq: intel_pstate: Fix divide by zero on Knights Landing (KNL)

2015-11-09T22:37:39+00:00

commit 8e601a9f97a00bab031980de34f9a81891c1f82f upstream.

This is a workaround for KNL platform, where in some cases MPERF counter
will not have updated value before next read of MSR_IA32_MPERF. In this
case divide by zero will occur. This change ignores current sample for
busy calculation in this case.

Fixes: b34ef932d79a (intel_pstate: Knights Landing support)
Signed-off-by: Srinivas Pandruvada 
Acked-by: Kristen Carlson Accardi 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

sched/deadline: Fix migration of SCHED_DEADLINE tasks

2015-11-09T22:37:39+00:00

commit 5aa5050787f449e7eaef2c5ec93c7b357aa7dcdc upstream.

Commit:

  9d5142624256 ("sched/deadline: Reduce rq lock contention by eliminating locking of non-feasible target")

broke select_task_rq_dl() and find_lock_later_rq(), because it introduced
a comparison between the local task's deadline and dl.earliest_dl.curr of
the remote queue.

However, if the remote runqueue does not contain any SCHED_DEADLINE
task its earliest_dl.curr is 0 (always smaller than the deadline of
the local task) and the remote runqueue is not selected for pushing.

As a result, if an application creates multiple SCHED_DEADLINE
threads, they will never be pushed to runqueues that do not already
contain SCHED_DEADLINE tasks.

This patch fixes the issue by checking if dl.dl_nr_running == 0.

Signed-off-by: Luca Abeni 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Juri Lelli 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Wanpeng Li 
Fixes: 9d5142624256 ("sched/deadline: Reduce rq lock contention by eliminating locking of non-feasible target")
Link: http://lkml.kernel.org/r/1444982781-15608-1-git-send-email-luca.abeni@unitn.it
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman