linux-toradex.git/drivers/xen, branch v4.1.20

xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY

2016-03-07T17:26:52+00:00

[ Upstream commit d52a24819677bbb45eb1ce93a42daa1ae6c4d61d ]

commit 8d47065f7d1980dde52abb874b301054f3013602 upstream.

Commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 (xen/pciback: Don't
allow MSI-X ops if PCI_COMMAND_MEMORY is not set) prevented enabling
MSI-X on passed-through virtual functions, because it checked the VF
for PCI_COMMAND_MEMORY but this is not a valid bit for VFs.

Instead, check the physical function for PCI_COMMAND_MEMORY.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set.

2016-03-07T17:26:48+00:00

[ Upstream commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 ]

commit f598282f51 ("PCI: Fix the NIU MSI-X problem in a better way")
teaches us that dealing with MSI-X can be troublesome.

Further checks in the MSI-X architecture shows that if the
PCI_COMMAND_MEMORY bit is turned of in the PCI_COMMAND we
may not be able to access the BAR (since they are memory regions).

Since the MSI-X tables are located in there.. that can lead
to us causing PCIe errors. Inhibit us performing any
operation on the MSI-X unless the MEMORY bit is set.

Note that Xen hypervisor with:
"x86/MSI-X: access MSI-X table only after having enabled MSI-X"
will return:
xen_pciback: 0000:0a:00.1: error -6 enabling MSI-X for guest 3!

When the generic MSI code tries to setup the PIRQ without
MEMORY bit set. Which means with later versions of Xen
(4.6) this patch is not neccessary.

This is part of XSA-157

CC: stable@vger.kernel.org
Reviewed-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Sasha Levin

xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled

2016-03-07T17:26:45+00:00

[ Upstream commit 5e0ce1455c09dd61d029b8ad45d82e1ac0b6c4c9 ]

The guest sequence of:

  a) XEN_PCI_OP_enable_msix
  b) XEN_PCI_OP_enable_msix

results in hitting an NULL pointer due to using freed pointers.

The device passed in the guest MUST have MSI-X capability.

The a) constructs and SysFS representation of MSI and MSI groups.
The b) adds a second set of them but adding in to SysFS fails (duplicate entry).
'populate_msi_sysfs' frees the newly allocated msi_irq_groups (note that
in a) pdev->msi_irq_groups is still set) and also free's ALL of the
MSI-X entries of the device (the ones allocated in step a) and b)).

The unwind code: 'free_msi_irqs' deletes all the entries and tries to
delete the pdev->msi_irq_groups (which hasn't been set to NULL).
However the pointers in the SysFS are already freed and we hit an
NULL pointer further on when 'strlen' is attempted on a freed pointer.

The patch adds a simple check in the XEN_PCI_OP_enable_msix to guard
against that. The check for msi_enabled is not stricly neccessary.

This is part of XSA-157

CC: stable@vger.kernel.org
Reviewed-by: David Vrabel 
Reviewed-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Sasha Levin

xen/pciback: Save the number of MSI-X entries to be copied later.

2016-03-07T17:26:27+00:00

[ Upstream commit 4cf5aa2ffe17403385d75a5b1d9d97071500ea18 ]

commit d159457b84395927b5a52adb72f748dd089ad5e5 upstream.

Commit 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 (xen/pciback: Save
xen_pci_op commands before processing it) broke enabling MSI-X because
it would never copy the resulting vectors into the response.  The
number of vectors requested was being overwritten by the return value
(typically zero for success).

Save the number of vectors before processing the op, so the correct
number of vectors are copied afterwards.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xen/pciback: Save xen_pci_op commands before processing it

2016-03-07T17:26:22+00:00

[ Upstream commit 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 ]

Double fetch vulnerabilities that happen when a variable is
fetched twice from shared memory but a security check is only
performed the first time.

The xen_pcibk_do_op function performs a switch statements on the op->cmd
value which is stored in shared memory. Interestingly this can result
in a double fetch vulnerability depending on the performed compiler
optimization.

This patch fixes it by saving the xen_pci_op command before
processing it. We also use 'barrier' to make sure that the
compiler does not perform any optimization.

This is part of XSA155.

CC: stable@vger.kernel.org
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Sasha Levin

xen/scsiback: correct frontend counting

2016-03-07T17:07:39+00:00

[ Upstream commit f285aa8db7cc4432c1a03f8b55ff34fe96317c11 ]

When adding a new frontend to xen-scsiback don't decrement the number
of active frontends in case of no error. Doing so results in a failure
when trying to remove the xen-pvscsi nexus even if no domain is using
it.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Cc: stable@vger.kernel.org
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen/gntdev: Grant maps should not be subject to NUMA balancing

2016-01-31T19:23:30+00:00

commit 9c17d96500f78d7ecdb71ca6942830158bc75a2b upstream.

Doing so will cause the grant to be unmapped and then, during
fault handling, the fault to be mistakenly treated as NUMA hint
fault.

In addition, even if those maps could partcipate in NUMA
balancing, it wouldn't provide any benefit since we are unable
to determine physical page's node (even if/when VNUMA is
implemented).

Marking grant maps' VMAs as VM_IO will exclude them from being
part of NUMA balancing.

Signed-off-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

sched/preempt, xen: Use need_resched() instead of should_resched()

2015-10-27T00:52:00+00:00

commit 0fa2f5cb2b0ecd8d56baa51f35f09aab234eb0bf upstream.

This code is used only when CONFIG_PREEMPT=n and only in non-atomic context:
xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall().
Thus preempt_count is zero and should_resched() is equal to need_resched().

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Graf 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20150715095201.12246.49283.stgit@buzz
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xen/xenbus: Don't leak memory when unmapping the ring on HVM backend

2015-09-13T16:07:40+00:00

commit c22fe519e7e2b94ad173e0ea3b89c1a7d8be8d00 upstream.

The commit ccc9d90a9a8b5c4ad7e9708ec41f75ff9e98d61d "xenbus_client:
Extend interface to support multi-page ring" removes the call to
free_xenballooned_pages() in xenbus_unmap_ring_vfree_hvm(), leaking a
page for every shared ring.

Only with backends running in HVM domains were affected.

Signed-off-by: Julien Grall 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/gntdevt: Fix race condition in gntdev_release()

2015-08-17T03:52:19+00:00

commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.

While gntdev_release() is called the MMU notifier is still registered
and can traverse priv->maps list even if no pages are mapped (which is
the case -- gntdev_release() is called after all). But
gntdev_release() will clear that list, so make sure that only one of
those things happens at the same time.

Signed-off-by: Marek Marczykowski-Górecki 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman