linux-stable.git/arch, branch v4.4.59

metag/ptrace: Reject partial NT_METAG_RPIPE writes

2017-03-31T07:49:54+00:00

commit 7195ee3120d878259e8d94a5d9f808116f34d5ea upstream.

It's not clear what behaviour is sensible when doing partial write of
NT_METAG_RPIPE, so just don't bother.

This patch assumes that userspace will never rely on a partial SETREGSET
in this case, since it's not clear what should happen anyway.

Signed-off-by: Dave Martin 
Acked-by: James Hogan 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

metag/ptrace: Provide default TXSTATUS for short NT_PRSTATUS

2017-03-31T07:49:54+00:00

commit 5fe81fe98123ce41265c65e95d34418d30d005d1 upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill TXSTATUS, a well-defined default value is used, based on the
task's current value.

Suggested-by: James Hogan 
Signed-off-by: Dave Martin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

metag/ptrace: Preserve previous registers for short regset write

2017-03-31T07:49:54+00:00

commit a78ce80d2c9178351b34d78fec805140c29c193e upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.

Signed-off-by: Dave Martin 
Acked-by: James Hogan 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

sparc/ptrace: Preserve previous registers for short regset write

2017-03-31T07:49:54+00:00

commit d3805c546b275c8cc7d40f759d029ae92c7175f2 upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.

Signed-off-by: Dave Martin 
Acked-by: David S. Miller 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mips/ptrace: Preserve previous registers for short regset write

2017-03-31T07:49:53+00:00

commit d614fd58a2834cfe4efa472c33c8f3ce2338b09b upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.

Signed-off-by: Dave Martin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

h8300/ptrace: Fix incorrect register transfer count

2017-03-31T07:49:53+00:00

commit 502585c7555083d4a949c08350306b9ec196779e upstream.

regs_set() and regs_get() are vulnerable to an off-by-1 buffer overrun
if CONFIG_CPU_H8S is set, since this adds an extra entry to
register_offset[] but not to user_regs_struct.

So, iterate over user_regs_struct based on its actual size, not based on
the length of register_offset[].

Signed-off-by: Dave Martin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

c6x/ptrace: Remove useless PTRACE_SETREGSET implementation

2017-03-31T07:49:53+00:00

commit fb411b837b587a32046dc4f369acb93a10b1def8 upstream.

gpr_set won't work correctly and can never have been tested, and the
correct behaviour is not clear due to the endianness-dependent task
layout.

So, just remove it.  The core code will now return -EOPNOTSUPPORT when
trying to set NT_PRSTATUS on this architecture until/unless a correct
implementation is supplied.

Signed-off-by: Dave Martin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic

2017-03-30T07:35:19+00:00

From: Vitaly Kuznetsov 

[ Upstream commit 59107e2f48831daedc46973ce4988605ab066de3 ]

There is a feature in Hyper-V ('Debug-VM --InjectNonMaskableInterrupt')
which injects NMI to the guest. We may want to crash the guest and do kdump
on this NMI by enabling unknown_nmi_panic. To make kdump succeed we need to
allow the kdump kernel to re-establish VMBus connection so it will see
VMBus devices (storage, network,..).

To properly unload VMBus making it possible to start over during kdump we
need to do the following:

 - Send an 'unload' message to the hypervisor. This can be done on any CPU
   so we do this the crashing CPU.

 - Receive the 'unload finished' reply message. WS2012R2 delivers this
   message to the CPU which was used to establish VMBus connection during
   module load and this CPU may differ from the CPU sending 'unload'.

Receiving a VMBus message means the following:

 - There is a per-CPU slot in memory for one message. This slot can in
   theory be accessed by any CPU.

 - We get an interrupt on the CPU when a message was placed into the slot.

 - When we read the message we need to clear the slot and signal the fact
   to the hypervisor. In case there are more messages to this CPU pending
   the hypervisor will deliver the next message. The signaling is done by
   writing to an MSR so this can only be done on the appropriate CPU.

To avoid doing cross-CPU work on crash we have vmbus_wait_for_unload()
function which checks message slots for all CPUs in a loop waiting for the
'unload finished' messages. However, there is an issue which arises when
these conditions are met:

 - We're crashing on a CPU which is different from the one which was used
   to initially contact the hypervisor.

 - The CPU which was used for the initial contact is blocked with interrupts
   disabled and there is a message pending in the message slot.

In this case we won't be able to read the 'unload finished' message on the
crashing CPU. This is reproducible when we receive unknown NMIs on all CPUs
simultaneously: the first CPU entering panic() will proceed to crash and
all other CPUs will stop themselves with interrupts disabled.

The suggested solution is to handle unknown NMIs for Hyper-V guests on the
first CPU which gets them only. This will allow us to rely on VMBus
interrupt handler being able to receive the 'unload finish' message in
case it is delivered to a different CPU.

The issue is not reproducible on WS2016 as Debug-VM delivers NMI to the
boot CPU only, WS2012R2 and earlier Hyper-V versions are affected.

Signed-off-by: Vitaly Kuznetsov 
Acked-by: K. Y. Srinivasan 
Cc: devel@linuxdriverproject.org
Cc: Haiyang Zhang 
Link: http://lkml.kernel.org/r/20161202100720.28121-1-vkuznets@redhat.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

xen: do not re-use pirq number cached in pci device msi msg data

2017-03-30T07:35:19+00:00

From: Dan Streetman 

[ Upstream commit c74fd80f2f41d05f350bb478151021f88551afe8 ]

Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")

That commit introduced reading the pci device's msi message data to see
if a pirq was previously configured for the device's msi/msix, and re-use
that pirq.  At the time, that was the correct behavior.  However, a
later change to Qemu caused it to call into the Xen hypervisor to unmap
all pirqs for a pci device, when the pci device disables its MSI/MSIX
vectors; specifically the Qemu commit:
c976437c7dba9c7444fb41df45468968aaa326ad
("qemu-xen: free all the pirqs for msi/msix when driver unload")

Once Qemu added this pirq unmapping, it was no longer correct for the
kernel to re-use the pirq number cached in the pci device msi message
data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
pirqs when the pci device disables its MSI/MSIX vectors.

This bug is causing failures to initialize multiple NVMe controllers
under Xen, because the NVMe driver sets up a single MSIX vector for
each controller (concurrently), and then after using that to talk to
the controller for some configuration data, it disables the single MSIX
vector and re-configures all the MSIX vectors it needs.  So the MSIX
setup code tries to re-use the cached pirq from the first vector
for each controller, but the hypervisor has already given away that
pirq to another controller, and its initialization fails.

This is discussed in more detail at:
https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html

Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
Signed-off-by: Dan Streetman 
Reviewed-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: at91: sama5d2: add dma properties to UART nodes

2017-03-30T07:35:18+00:00

commit b1708b72a0959a032cd2eebb77fa9086ea3e0c84 upstream.

The dmas/dma-names properties are added to the UART nodes. Note that additional
properties are needed to enable them at the board level: check bindings for
details.

Signed-off-by: Nicolas Ferre 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman