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

xen/gntdev: Fix partial gntdev_mmap() cleanup

2018-03-03T09:19:45+00:00

[ Upstream commit cf2acf66ad43abb39735568f55e1f85f9844e990 ]

When cleaning up after a partially successful gntdev_mmap(), unmap the
successfully mapped grant pages otherwise Xen will kill the domain if
in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will
kill the process and emit "BUG: Bad page map in process" if Xen is in
release mode.

This is only needed when use_ptemod is true because gntdev_put_map()
will unmap grant pages itself when use_ptemod is false.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/gntdev: Fix off-by-one error when unmapping with holes

2018-03-03T09:19:45+00:00

[ Upstream commit 951a010233625b77cde3430b4b8785a9a22968d1 ]

If the requested range has a hole, the calculation of the number of
pages to unmap is off by one. Fix it.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen: XEN_ACPI_PROCESSOR is Dom0-only

2018-02-25T10:03:41+00:00

[ Upstream commit c4f9d9cb2c29ff04c6b4bb09b72802d8aedfc7cb ]

Add a respective dependency.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen: xenbus driver must not accept invalid transaction ids

2017-11-30T08:37:28+00:00

[ Upstream commit 639b08810d6ad74ded2c5f6e233c4fcb9d147168 ]

When accessing Xenstore in a transaction the user is specifying a
transaction id which he normally obtained from Xenstore when starting
the transaction. Xenstore is validating a transaction id against all
known transaction ids of the connection the request came in. As all
requests of a domain not being the one where Xenstore lives share
one connection, validation of transaction ids of different users of
Xenstore in that domain should be done by the kernel of that domain
being the multiplexer between the Xenstore users in that domain and
Xenstore.

In order to prohibit one Xenstore user "hijacking" a transaction from
another user the xenbus driver has to verify a given transaction id
against all known transaction ids of the user before forwarding it to
Xenstore.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen: don't print error message in case of missing Xenstore entry

2017-11-08T09:06:30+00:00

[ Upstream commit 4e93b6481c87ea5afde944a32b4908357ec58992 ]

When registering for the Xenstore watch of the node control/sysrq the
handler will be called at once. Don't issue an error message if the
Xenstore node isn't there, as it will be created only when an event
is being triggered.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/manage: correct return value check on xenbus_scanf()

2017-11-08T09:06:30+00:00

[ Upstream commit 4fed1b125eb6252bde478665fc05d4819f774fa8 ]

A negative return value indicates an error; in fact the function at
present won't ever return zero.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

2017-11-02T08:40:49+00:00

commit 298d275d4d9bea3524ff4bc76678c140611d8a8d upstream.

In case gntdev_mmap() succeeds only partially in mapping grant pages
it will leave some vital information uninitialized needed later for
cleanup. This will lead to an out of bounds array access when unmapping
the already mapped pages.

So just initialize the data needed for unmapping the pages a little bit
earlier.

Reported-by: Arthur Borsboom 
Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

fix xen_swiotlb_dma_mmap prototype

2017-10-05T07:41:48+00:00

xen_swiotlb_dma_mmap was backported from v4.10, but older
kernels before commit 00085f1efa38 ("dma-mapping: use unsigned long
for dma_attrs") use a different signature:

arm/xen/mm.c:202:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .mmap = xen_swiotlb_dma_mmap,
          ^~~~~~~~~~~~~~~~~~~~
arm/xen/mm.c:202:10: note: (near initialization for 'xen_swiotlb_dma_ops.mmap')

This adapts the patch to the old calling conventions.

Fixes: "swiotlb-xen: implement xen_swiotlb_dma_mmap callback"
Signed-off-by: Arnd Bergmann 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Greg Kroah-Hartman

swiotlb-xen: implement xen_swiotlb_dma_mmap callback

2017-10-05T07:41:48+00:00

commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.

This function creates userspace mapping for the DMA-coherent memory.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Andrii Anisov 
Signed-off-by: Konrad Rzeszutek Wilk 
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