linux-stable.git/drivers/xen, branch linux-4.5.y

xen/events: Don't move disabled irqs

2016-06-08T01:18:51+00:00

commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream.

Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded
irq_move_irq() but left out checking if the IRQ is disabled. This broke
resuming from suspend since it tries to move a (disabled) irq without
holding the IRQ's desc->lock. Fix it by adding in a check for disabled
IRQs.

The resulting stacktrace was:
kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31!
invalid opcode: 0000 [#1] SMP
Modules linked in: xenfs xen_privcmd ...
CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu
Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016
task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000
RIP: 0010:[]  [] irq_move_masked_irq+0xd2/0xe0
RSP: 0018:ffff88003d7bfc50  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001
RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8
RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000
R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0
R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff
FS:  0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
 ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0
 ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009
 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66
Call Trace:
 [] eoi_pirq+0xb2/0xf0
 [] __startup_pirq+0xe6/0x150
 [] xen_irq_resume+0x319/0x360
 [] xen_suspend+0xb5/0x180
 [] multi_cpu_stop+0xb5/0xe0
 [] ? cpu_stop_queue_work+0x80/0x80
 [] cpu_stopper_thread+0xb0/0x140
 [] ? finish_task_switch+0x76/0x220
 [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
 [] smpboot_thread_fn+0x105/0x160
 [] ? sort_range+0x30/0x30
 [] kthread+0xd8/0xf0
 [] ? kthread_create_on_node+0x1e0/0x1e0
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x1e0/0x1e0

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

xen/evtchn: fix ring resize when binding new events

2016-05-11T09:21:34+00:00

commit 27e0e6385377c4dc68a4ddaf1a35a2dfa951f3c5 upstream.

The copying of ring data was wrong for two cases: For a full ring
nothing got copied at all (as in that case the canonicalized producer
and consumer indexes are identical). And in case one or both of the
canonicalized (after the resize) indexes would point into the second
half of the buffer, the copied data ended up in the wrong (free) part
of the new buffer. In both cases uninitialized data would get passed
back to the caller.

Fix this by simply copying the old ring contents twice: Once to the
low half of the new buffer, and a second time to the high half.

This addresses the inability to boot a HVM guest with 64 or more
vCPUs.  This regression was caused by 8620015499101090 (xen/evtchn:
dynamically grow pending event channel ring).

Reported-by: Konrad Rzeszutek Wilk 
Signed-off-by: Jan Beulich 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/balloon: Fix crash when ballooning on x86 32 bit PAE

2016-05-11T09:21:33+00:00

commit dfd74a1edfaba5864276a2859190a8d242d18952 upstream.

Commit 55b3da98a40dbb3776f7454daf0d95dde25c33d2 (xen/balloon: find
non-conflicting regions to place hotplugged memory) caused a
regression in 4.4.

When ballooning on an x86 32 bit PAE system with close to 64 GiB of
memory, the address returned by allocate_resource may be above 64 GiB.
When using CONFIG_SPARSEMEM, this setup is limited to using physical
addresses < 64 GiB.  When adding memory at this address, it runs off
the end of the mem_section array and causes a crash.  Instead, fail
the ballooning request.

Signed-off-by: Ross Lagerwall 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

xen/events: Mask a moving irq

2016-04-20T06:45:10+00:00

commit ff1e22e7a638a0782f54f81a6c9cb139aca2da35 upstream.

Moving an unmasked irq may result in irq handler being invoked on both
source and target CPUs.

With 2-level this can happen as follows:

On source CPU:
        evtchn_2l_handle_events() ->
            generic_handle_irq() ->
                handle_edge_irq() ->
                   eoi_pirq():
                       irq_move_irq(data);

                       /***** WE ARE HERE *****/

                       if (VALID_EVTCHN(evtchn))
                           clear_evtchn(evtchn);

If at this moment target processor is handling an unrelated event in
evtchn_2l_handle_events()'s loop it may pick up our event since target's
cpu_evtchn_mask claims that this event belongs to it *and* the event is
unmasked and still pending. At the same time, source CPU will continue
executing its own handle_edge_irq().

With FIFO interrupt the scenario is similar: irq_move_irq() may result
in a EVTCHNOP_unmask hypercall which, in turn, may make the event
pending on the target CPU.

We can avoid this situation by moving and clearing the event while
keeping event masked.

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

Merge tag 'for-linus-4.5-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2016-02-22T21:57:01+00:00

Pull xen bug fixes from David Vrabel:

 - Two scsiback fixes (resource leak and spurious warning).

 - Fix DMA mapping of compound pages on arm/arm64.

 - Fix some pciback regressions in MSI-X handling.

 - Fix a pcifront crash due to some uninitialize state.

* tag 'for-linus-4.5-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.
  xen/pcifront: Report the errors better.
  xen/pciback: Save the number of MSI-X entries to be copied later.
  xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY
  xen: fix potential integer overflow in queue_reply
  xen/arm: correctly handle DMA mapping of compound pages
  xen/scsiback: avoid warnings when adding multiple LUNs to a domain
  xen/scsiback: correct frontend counting

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

2016-02-15T14:21:10+00:00

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 
Cc: 
Reviewed-by: Jan Beulich 
Signed-off-by: David Vrabel

xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY

2016-02-15T14:00:34+00:00

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 
Cc: 
Reviewed-by: Jan Beulich 
Signed-off-by: David Vrabel

xen: fix potential integer overflow in queue_reply

2016-02-15T13:56:57+00:00

When len is greater than UINT_MAX - sizeof(*rb), in next allocation,
it can overflow integer range and allocates small size of heap.
After that, memcpy will overflow the allocated heap.
Therefore, it needs to check the size of given length.

Signed-off-by: Insu Yun 
Signed-off-by: David Vrabel

xen/scsiback: avoid warnings when adding multiple LUNs to a domain

2016-02-08T16:51:36+00:00

When adding more than one LUN to a frontend a warning for a failed
assignment is issued in dom0 for each already existing LUN. Avoid this
warning by checking for a LUN already existing when existence is
allowed (scsiback_do_add_lun() called with try == 1).

As the LUN existence check is needed now for a third time, factor it
out into a function. This in turn leads to a more or less complete
rewrite of scsiback_del_translation_entry() which will now return a
proper error code in case of failure.

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: David Vrabel

xen/scsiback: correct frontend counting

2016-02-08T16:44:40+00:00

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