summaryrefslogtreecommitdiffstats
path: root/arch/s390/kvm/kvm-s390.h
diff options
context:
space:
mode:
authorJan Glauber <jang@linux.vnet.ibm.com>2011-07-24 10:48:00 +0200
committerMartin Schwidefsky <schwidefsky@de.ibm.com>2011-07-24 10:48:00 +0200
commitb02f0c2ea25781e0f94b4fc8f6f85582057857b3 (patch)
tree688ed8fea4f857f5280be3f4d8adae663fea3d4b /arch/s390/kvm/kvm-s390.h
parent50a15981a1fac7e019ff7c3cba87531fb580f065 (diff)
downloadblackbird-op-linux-b02f0c2ea25781e0f94b4fc8f6f85582057857b3.tar.gz
blackbird-op-linux-b02f0c2ea25781e0f94b4fc8f6f85582057857b3.zip
[S390] qdio: clear shared DSCI before scheduling the queue handler
The following race can occur with qdio devices that use the shared device state change indicator: Device (Shared DSCI) CPU0 CPU1 =============================================================================== 1. DSCI 0 => 1, INT pending 2. Thinint handler * si_used = 1 * Inbound tasklet_schedule * DSCI 1 => 0 3. DSCI 0 => 1, INT pending 4. Thinint handler * si_used = 1 * Inbound tasklet_schedu le => NOP 5. Inbound tasklet run 6. DSCI = 1, INT surpressed 7. DSCI 1 => 0 The race would lead to a stall where new data in the input queue is not recognized so the device stops working in case of no further traffic. Fix the race by resetting the DSCI before scheduling the inbound tasklet so the device generates an interrupt if new data arrives in the above scenario in step 6. Reviewed-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Diffstat (limited to 'arch/s390/kvm/kvm-s390.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud