[Xen-devel] [PATCH] xen-blkfront: use a right index when checking requests
Since commit d05d7f40791c ("Merge branch 'for-4.8/core' of
git://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch
'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume()
has been using an index for iterating ring_info to check request when
iterating blk_shadow in an inner loop. This seems to have been
accidentally introduced during the massive rewrite of the block layer
macros in the commits.
This may cause crash like this:
[11798.057074] BUG: unable to handle kernel NULL pointer dereference at
0048
[11798.058832] IP: [] blkfront_resume+0x10a/0x610
[11798.061063] Call Trace:
[11798.061063] [] xenbus_dev_resume+0x53/0x140
[11798.061063] [] ? xenbus_dev_probe+0x150/0x150
[11798.061063] [] dpm_run_callback+0x3e/0x110
[11798.061063] [] device_resume+0x88/0x190
[11798.061063] [] dpm_resume+0x100/0x2d0
[11798.061063] [] dpm_resume_end+0x11/0x20
[11798.061063] [] do_suspend+0xe8/0x1a0
[11798.061063] [] shutdown_handler+0xfd/0x130
[11798.061063] [] ? split+0x110/0x110
[11798.061063] [] xenwatch_thread+0x86/0x120
[11798.061063] [] ? prepare_to_wait_event+0x110/0x110
[11798.061063] [] kthread+0xd7/0xf0
[11798.061063] [] ? kfree+0x121/0x170
[11798.061063] [] ? kthread_park+0x60/0x60
[11798.061063] [] ? call_usermodehelper_exec_work+0xb0/0xb0
[11798.061063] [] ?
call_usermodehelper_exec_async+0x13a/0x140
[11798.061063] [] ret_from_fork+0x25/0x30
Use the right index in the inner loop.
Fixes: d05d7f40791c ("Merge branch 'for-4.8/core' of
git://git.kernel.dk/linux-block")
Fixes: 3fc9d690936f ("Merge branch 'for-4.8/drivers' of
git://git.kernel.dk/linux-block")
Signed-off-by: Munehisa Kamata <kama...@amazon.com>
Reviewed-by: Thomas Friebel <frieb...@amazon.de>
Reviewed-by: Eduardo Valentin <edu...@amazon.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: Juergen Gross <jgr...@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Roger Pau Monne <roger@citrix.com>
Cc: xen-de...@lists.xenproject.org
Cc: sta...@vger.kernel.org
---
drivers/block/xen-blkfront.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 98e34e4c62b8..2468c28d4771 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2075,9 +2075,9 @@ static int blkfront_resume(struct xenbus_device *dev)
/*
* Get the bios in the request so we can re-queue them.
*/
- if (req_op(shadow[i].request) == REQ_OP_FLUSH ||
- req_op(shadow[i].request) == REQ_OP_DISCARD ||
- req_op(shadow[i].request) == REQ_OP_SECURE_ERASE ||
+ if (req_op(shadow[j].request) == REQ_OP_FLUSH ||
+ req_op(shadow[j].request) == REQ_OP_DISCARD ||
+ req_op(shadow[j].request) == REQ_OP_SECURE_ERASE ||
shadow[j].request->cmd_flags & REQ_FUA) {
/*
* Flush operations don't contain bios, so
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/events: don't migrate disabled IRQs
Commit ff1e22e7a638 ("xen/events: Mask a moving irq") introduced
a crash below. This can be triggered after being resumed from suspend
(e.g. live migration) if there are disabled IRQs with
IRQD_SETAFFINITY_PENDING set.
kernel BUG at kernel/irq/migration.c:31!
...
CPU: 0 PID: 9 Comm: migration/0 Tainted: GE 4.4.8 #1
Hardware name: Xen HVM domU, BIOS 4.2.amazon 04/04/2016
task: 88020620 ti: 880206208000 task.ti: 880206208000
RIP: 0010:[] []
irq_move_masked_irq+0xd9/0xf0
RSP: 0018:88020620bc88 EFLAGS: 00010046
...
Call Trace:
[] eoi_pirq+0xa7/0xd0
[] __startup_pirq+0xd7/0x140
[] xen_irq_resume+0x2c7/0x330
[] xen_suspend+0x86/0x140
[] multi_cpu_stop+0xb3/0xe0
[] ? cpu_stop_queue_work+0x80/0x80
[] cpu_stopper_thread+0x7a/0x110
[] ? finish_task_switch+0x72/0x1d0
[] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
[] smpboot_thread_fn+0x10f/0x170
[] ? sort_range+0x30/0x30
[] kthread+0xc9/0xe0
[] ? kthread_park+0x60/0x60
[] ret_from_fork+0x3f/0x70
[] ? kthread_park+0x60/0x60
The pending state may last until being suspended, because some IRQs may
show no activities after their affinity settings have been changed.
This change don't let ACK and EOI handlers of xen-pirq and xen-dyn chips
try to migrate disabled IRQs to avoid the BUG in that situation.
Fixes: ff1e22e7a638 ("xen/events: Mask a moving irq")
Reported-and-tested-by: Guilherme Wuensch Manika <gman...@amazon.de>
To: Boris Ostrovsky <boris.ostrov...@oracle.com>
To: David Vrabel <david.vra...@citrix.com>
Cc: xen-de...@lists.xenproject.org
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: Matt Wilson <m...@amazon.com>
Signed-off-by: Munehisa Kamata <kama...@amazon.com>
---
drivers/xen/events/events_base.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index cb7138c..be8410f 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -487,7 +487,8 @@ static void eoi_pirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
- if (unlikely(irqd_is_setaffinity_pending(data))) {
+ if (unlikely(irqd_is_setaffinity_pending(data) &&
+ !irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
clear_evtchn(evtchn);
@@ -1370,7 +1371,8 @@ static void ack_dynirq(struct irq_data *data)
if (!VALID_EVTCHN(evtchn))
return;
- if (unlikely(irqd_is_setaffinity_pending(data))) {
+ if (unlikely(irqd_is_setaffinity_pending(data) &&
+ !irqd_irq_disabled(data))) {
int masked = test_and_set_mask(evtchn);
clear_evtchn(evtchn);
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
