summaryrefslogtreecommitdiff
path: root/drivers/vhost
diff options
context:
space:
mode:
authorHalil Pasic <pasic@linux.ibm.com>2018-09-26 19:48:30 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-12-13 11:16:18 +0300
commit2a622040a8bce2bb7e646ca73a328b4e86ba336f (patch)
treedba6ac90dfacd320bcc2316feb38442ae2311e44 /drivers/vhost
parent79f6e9facb8b53ef2097a9aa35c7069b5627301a (diff)
downloadlinux-2a622040a8bce2bb7e646ca73a328b4e86ba336f.tar.xz
virtio/s390: fix race in ccw_io_helper()
commit 78b1a52e05c9db11d293342e8d6d8a230a04b4e7 upstream. While ccw_io_helper() seems like intended to be exclusive in a sense that it is supposed to facilitate I/O for at most one thread at any given time, there is actually nothing ensuring that threads won't pile up at vcdev->wait_q. If they do, all threads get woken up and see the status that belongs to some other request than their own. This can lead to bugs. For an example see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432 This race normally does not cause any problems. The operations provided by struct virtio_config_ops are usually invoked in a well defined sequence, normally don't fail, and are normally used quite infrequent too. Yet, if some of the these operations are directly triggered via sysfs attributes, like in the case described by the referenced bug, userspace is given an opportunity to force races by increasing the frequency of the given operations. Let us fix the problem by ensuring, that for each device, we finish processing the previous request before starting with a new one. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reported-by: Colin Ian King <colin.king@canonical.com> Cc: stable@vger.kernel.org Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/vhost')
0 files changed, 0 insertions, 0 deletions