linux-stable.git/drivers/xen, branch v3.16.69

xen-swiotlb: use actually allocated size on check physical continuous

2019-02-11T17:53:38+00:00

commit 7250f422da0480d8512b756640f131b9b893ccda upstream.

xen_swiotlb_{alloc,free}_coherent() allocate/free memory based on the
order of the pages and not size argument (bytes). This is inconsistent with
range_straddles_page_boundary and memset which use the 'size' value,
which may lead to not exchanging memory with Xen (range_straddles_page_boundary()
returned true). And then the call to xen_swiotlb_free_coherent() would
actually try to exchange the memory with Xen, leading to the kernel
hitting an BUG (as the hypercall returned an error).

This patch fixes it by making the 'size' variable be of the same size
as the amount of memory allocated.

Signed-off-by: Joe Jin 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: Christoph Helwig 
Cc: Dongli Zhang 
Cc: John Sobecki 
Signed-off-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.16:
 - Use PAGE_SHIFT instead of XEN_PAGE_SHIFT
 - Adjust context]
Signed-off-by: Ben Hutchings

xen: Remove unnecessary BUG_ON from __unbind_from_irq()

2018-11-20T18:05:23+00:00

commit eef04c7b3786ff0c9cb1019278b6c6c2ea0ad4ff upstream.

Commit 910f8befdf5b ("xen/pirq: fix error path cleanup when binding
MSIs") fixed a couple of errors in error cleanup path of
xen_bind_pirq_msi_to_irq(). This cleanup allowed a call to
__unbind_from_irq() with an unbound irq, which would result in
triggering the BUG_ON there.

Since there is really no reason for the BUG_ON (xen_free_irq() can
operate on unbound irqs) we can remove it.

Reported-by: Ben Hutchings 
Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Signed-off-by: Juergen Gross 
Signed-off-by: Ben Hutchings

xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

2018-10-21T07:46:14+00:00

commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.

When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
but Dom Heap is increased by the same size. Tracing raidconfig we found
that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
to apply memory. If the memory allocated by Dom0 is not in the DMA area,
it will exchange memory with Xen to meet the requiment. Later drivers
call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
the check condition (dev_addr + size - 1 <= dma_mask) is always false,
it prevents calling xen_destroy_contiguous_region() to return the memory
to the Xen DMA heap.

This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".

Signed-off-by: Joe Jin 
Tested-by: John Sobecki 
Reviewed-by: Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

xen/acpi: off by one in read_acpi_id()

2018-10-21T07:45:06+00:00

commit c37a3c94775855567b90f91775b9691e10bd2806 upstream.

If acpi_id is == nr_acpi_bits, then we access one element beyond the end
of the acpi_psd[] array or we set one bit beyond the end of the bit map
when we do __set_bit(acpi_id, acpi_id_present);

Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.")
Signed-off-by: Dan Carpenter 
Reviewed-by: Joao Martins 
Reviewed-by: Juergen Gross 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Ben Hutchings

xen/pirq: fix error path cleanup when binding MSIs

2018-06-16T21:22:30+00:00

commit 910f8befdf5bccf25287d9f1743e3e546bcb7ce0 upstream.

Current cleanup in the error path of xen_bind_pirq_msi_to_irq is
wrong. First of all there's an off-by-one in the cleanup loop, which
can lead to unbinding wrong IRQs.

Secondly IRQs not bound won't be freed, thus leaking IRQ numbers.

Note that there's no need to differentiate between bound and unbound
IRQs when freeing them, __unbind_from_irq will deal with both of them
correctly.

Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi 
Signed-off-by: Roger Pau Monné 
Reviewed-by: Amit Shah 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: Juergen Gross 
Signed-off-by: Ben Hutchings

xen: Add xen_arch_suspend()

2018-06-16T21:22:30+00:00

This is based on commit 2b953a5e994ce279904ec70220f7d4f31d380a0a
upstream, "xen: Suspend ticks on all CPUs during suspend", but
excluding the bug fix in that commit which is not needed in 3.16.
We only need the xen_arch_suspend() hook for the following fix.

Cc: Boris Ostrovsky 
Cc: David Vrabel 
Signed-off-by: Ben Hutchings

xen/events: events_fifo: Don't use {get,put}_cpu() in xen_evtchn_fifo_init()

2017-11-26T13:50:28+00:00

commit 22f12f0df802cea865672d8f39fbebdc03981050 upstream.

When booting Linux as Xen guest with CONFIG_DEBUG_ATOMIC, the following
splat appears:

[    0.002323] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)
[    0.019717] ASID allocator initialised with 65536 entries
[    0.020019] xen:grant_table: Grant tables using version 1 layout
[    0.020051] Grant table initialized
[    0.020069] BUG: sleeping function called from invalid context at /data/src/linux/mm/page_alloc.c:4046
[    0.020100] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
[    0.020123] no locks held by swapper/0/1.
[    0.020143] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc5 #598
[    0.020166] Hardware name: FVP Base (DT)
[    0.020182] Call trace:
[    0.020199] [] dump_backtrace+0x0/0x270
[    0.020222] [] show_stack+0x24/0x30
[    0.020244] [] dump_stack+0xb8/0xf0
[    0.020267] [] ___might_sleep+0x1c8/0x1f8
[    0.020291] [] __might_sleep+0x58/0x90
[    0.020313] [] __alloc_pages_nodemask+0x1c0/0x12e8
[    0.020338] [] alloc_page_interleave+0x38/0x88
[    0.020363] [] alloc_pages_current+0xdc/0xf0
[    0.020387] [] __get_free_pages+0x28/0x50
[    0.020411] [] evtchn_fifo_alloc_control_block+0x2c/0xa0
[    0.020437] [] xen_evtchn_fifo_init+0x38/0xb4
[    0.020461] [] xen_init_IRQ+0x44/0xc8
[    0.020484] [] xen_guest_init+0x250/0x300
[    0.020507] [] do_one_initcall+0x44/0x130
[    0.020531] [] kernel_init_freeable+0x120/0x288
[    0.020556] [] kernel_init+0x18/0x110
[    0.020578] [] ret_from_fork+0x10/0x40
[    0.020606] xen:events: Using FIFO-based ABI
[    0.020658] Xen: initializing cpu0
[    0.027727] Hierarchical SRCU implementation.
[    0.036235] EFI services will not be available.
[    0.043810] smp: Bringing up secondary CPUs ...

This is because get_cpu() in xen_evtchn_fifo_init() will disable
preemption, but __get_free_page() might sleep (GFP_ATOMIC is not set).

xen_evtchn_fifo_init() will always be called before SMP is initialized,
so {get,put}_cpu() could be replaced by a simple smp_processor_id().

This also avoid to modify evtchn_fifo_alloc_control_block that will be
called in other context.

Signed-off-by: Julien Grall 
Reported-by: Andre Przywara 
Reviewed-by: Boris Ostrovsky 
Fixes: 1fe565517b57 ("xen/events: use the FIFO-based ABI if available")
Signed-off-by: Boris Ostrovsky 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

xen: fix bio vec merging

2017-09-15T17:30:18+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 
[bwh: Backported to 3.16:
 - s/bfn/mfn/g
 - Adjust context]
Signed-off-by: Ben Hutchings

xen/acpi: upload PM state from init-domain to Xen

2017-07-18T17:40:22+00:00

commit 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.

This was broken in commit cd979883b9ed ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)

The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.

Cc: Stanislaw Gruszka 
Based-on-patch-by: Konrad Wilk 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Stanislaw Gruszka 
Signed-off-by: Ankur Arora 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Ben Hutchings

xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

2017-03-16T02:26:25+00:00

commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.

Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.

It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.

check_vma_flags
__get_user_pages
__get_user_pages_locked
__get_user_pages_unlocked
get_user_pages_fast
iov_iter_get_pages
dio_refill_pages
do_direct_IO
do_blockdev_direct_IO
do_blockdev_direct_IO
ext4_direct_IO_read
generic_file_read_iter
aio_run_iocb

(which can happen if guest's vdisk has direct-io-safe option).

To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
NUMA balancing just as VM_IO does and has no effect on
check_vma_flags().


Reported-by: Olaf Hering 
Suggested-by: Hugh Dickins 
Signed-off-by: Boris Ostrovsky 
Acked-by: Hugh Dickins 
Tested-by: Olaf Hering 
Signed-off-by: Juergen Gross 
Signed-off-by: Ben Hutchings