similar to: [PATCH 00/18] virtio-blk: Support "VIRTIO_CONFIG_S_NEEDS_RESET"

On Tue, Apr 21, 2015 at 10:37:00AM +0800, Fam Zheng wrote: > On Mon, 04/20 19:36, Michael S. Tsirkin wrote: > > On Fri, Apr 17, 2015 at 03:59:15PM +0800, Fam Zheng wrote: > > > Currently, virtio code chooses to kill QEMU if the guest passes any invalid > > > data with vring. > > > That has drawbacks such as losing unsaved data (e.g. when > > > guest

On Tue, Apr 21, 2015 at 10:37:00AM +0800, Fam Zheng wrote: > On Mon, 04/20 19:36, Michael S. Tsirkin wrote: > > On Fri, Apr 17, 2015 at 03:59:15PM +0800, Fam Zheng wrote: > > > Currently, virtio code chooses to kill QEMU if the guest passes any invalid > > > data with vring. > > > That has drawbacks such as losing unsaved data (e.g. when > > > guest

On Tue, 04/21 07:22, Michael S. Tsirkin wrote: > On Tue, Apr 21, 2015 at 10:37:00AM +0800, Fam Zheng wrote: > > On Mon, 04/20 19:36, Michael S. Tsirkin wrote: > > > On Fri, Apr 17, 2015 at 03:59:15PM +0800, Fam Zheng wrote: > > > > Currently, virtio code chooses to kill QEMU if the guest passes any invalid > > > > data with vring. > > > > That

On Mon, 04/20 19:36, Michael S. Tsirkin wrote: > On Fri, Apr 17, 2015 at 03:59:15PM +0800, Fam Zheng wrote: > > Currently, virtio code chooses to kill QEMU if the guest passes any invalid > > data with vring. > > That has drawbacks such as losing unsaved data (e.g. when > > guest user is writing a very long email), or possible denial of service in > > a nested vm

On Mon, Apr 20, 2015 at 09:10:02PM +0200, Paolo Bonzini wrote: > > > On 20/04/2015 19:36, Michael S. Tsirkin wrote: > > At the implementation level, there's one big issue you seem to have > > missed: DMA to invalid memory addresses causes a crash in memory core. > > I'm not sure whether it makes sense to recover from virtio core bugs > > when we can't

On Mon, Apr 20, 2015 at 09:10:02PM +0200, Paolo Bonzini wrote: > > > On 20/04/2015 19:36, Michael S. Tsirkin wrote: > > At the implementation level, there's one big issue you seem to have > > missed: DMA to invalid memory addresses causes a crash in memory core. > > I'm not sure whether it makes sense to recover from virtio core bugs > > when we can't

On 20/04/2015 19:36, Michael S. Tsirkin wrote: > At the implementation level, there's one big issue you seem to have > missed: DMA to invalid memory addresses causes a crash in memory core. > I'm not sure whether it makes sense to recover from virtio core bugs > when we can't recover from device bugs. What do you mean exactly? DMA to invalid memory addresses causes

On 20/04/2015 22:34, Michael S. Tsirkin wrote: > On Mon, Apr 20, 2015 at 09:10:02PM +0200, Paolo Bonzini wrote: >> >> >> On 20/04/2015 19:36, Michael S. Tsirkin wrote: >>> At the implementation level, there's one big issue you seem to have >>> missed: DMA to invalid memory addresses causes a crash in memory core. >>> I'm not sure whether it

Hi Jens, my colleague Eduardo is sporadically seeing an Oops in blk-mq while running continuous virtio_blk hot-plug/hot-unplug tests with I/O to the device within an x86_64 QEMU/KVM 2.0 Debian Wheezy VM. Please find the call trace attached and the full log here: http://paste.ubuntu.com/9691873/ The kernel image has been taken from here and is the mainline kernel from tag v3.18:

Hi Jens, my colleague Eduardo is sporadically seeing an Oops in blk-mq while running continuous virtio_blk hot-plug/hot-unplug tests with I/O to the device within an x86_64 QEMU/KVM 2.0 Debian Wheezy VM. Please find the call trace attached and the full log here: http://paste.ubuntu.com/9691873/ The kernel image has been taken from here and is the mainline kernel from tag v3.18:

On Tue, 06/28 04:45, Christoph Hellwig wrote: > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > > point we haven't created the serial attribute file, therefore depending > > on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get > > created. > > >

On Tue, 06/28 04:45, Christoph Hellwig wrote: > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > > point we haven't created the serial attribute file, therefore depending > > on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get > > created. > > >

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in systemd, there used to be a related workaround in udev rules called

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of virtio-blk disks. Also in systemd, there used to be a related workaround in udev rules called

On Fri, 01/09 15:32, Sebastian Parschauer wrote: > Hi Jens, > > my colleague Eduardo is sporadically seeing an Oops in blk-mq while > running continuous virtio_blk hot-plug/hot-unplug tests with I/O to the > device within an x86_64 QEMU/KVM 2.0 Debian Wheezy VM. > > Please find the call trace attached and the full log here: > http://paste.ubuntu.com/9691873/ > >

On Fri, 01/09 15:32, Sebastian Parschauer wrote: > Hi Jens, > > my colleague Eduardo is sporadically seeing an Oops in blk-mq while > running continuous virtio_blk hot-plug/hot-unplug tests with I/O to the > device within an x86_64 QEMU/KVM 2.0 Debian Wheezy VM. > > Please find the call trace attached and the full log here: > http://paste.ubuntu.com/9691873/ > >

On Wed, Jun 29, 2016 at 09:24:15AM +0800, Fam Zheng wrote: > On Tue, 06/28 04:45, Christoph Hellwig wrote: > > On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > > > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > > > point we haven't created the serial attribute file, therefore depending > > > on how fast udev reacts, the

On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote: > Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that > point we haven't created the serial attribute file, therefore depending > on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get > created. > > This race condition can be easily reproduced by hot plugging a number of >

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk