[Bug 1967814] Re: Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having miscompares on disktests when there is a failed path.

[Frank Heimes]

Changing the affected package from "linux (Ubuntu)" (kernel) to "qemu
(Ubuntu)" as affected package, since the attached patch set is for qemu.

** Package changed: linux (Ubuntu) => qemu (Ubuntu)

** Also affects: qemu
   Importance: Undecided
       Status: New

** No longer affects: qemu

** Also affects: ubuntu-z-systems
   Importance: Undecided
       Status: New

** Changed in: ubuntu-z-systems
     Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Changed in: qemu (Ubuntu)
     Assignee: Skipper Bug Screeners (skipper-screen-team) => Canonical Server 
Team (canonical-server)

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1967814

Title:
  Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having
  miscompares on disktests when there is a failed path.

Status in Ubuntu on IBM z Systems:
  New
Status in qemu package in Ubuntu:
  New
Status in qemu source package in Focal:
  New

Bug description:
  == Comment: #63 - Halil Pasic <PASIC@de.ibm.com> - 2022-03-28 17:33:34 ==
  I'm pretty confident I've figured out what is going on. 

  From the guest side, the decision whether the SCSI command was completed 
successfully or not comes down to looking at the sense data. Prior to commit
  a108557bbf ("scsi: inline sg_io_sense_from_errno() into the callers."), we 
don't
  build sense data as a response to seeing a host status presented by the host 
SCSI stack (e.g. kernel).

  Thus when the kernel tells us that  a given SCSI command did not get 
completed via
  SCSI_HOST_TRANSPORT_DISRUPTED or SCSI_HOST_NO_LUN, we end up  fooling the 
guest into believing that the command completed successfully.

  The guest kernel, and especially virtio and multipath are at no fault
  (AFAIU). Given these facts, it isn't all that surprising, that we end
  up with corruptions.

  All we have to do is do backports for QEMU (when necessary). I didn't
  investigate vhost-scsi -- my guess is, that it ain't affected.

  How do we want to handle the back-ports?

  == Comment: #66 - Halil Pasic <PASIC@de.ibm.com> - 2022-04-04 05:36:33 ==
  This is a proposed backport containing 7 patches in mbox format. I tried to 
pick patches sanely, and all I had to do was basically resolving merge 
conflicts.

  I have to admit I have no extensive experience in doing such invasive
  backports, and my knowledge of the QEMU SCSI stack is very limited. I
  would be happy if the Ubuntu folks would have a good look at this, and
  if possible improve on it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1967814/+subscriptions