summary refs log tree commit diff stats
path: root/results/classifier/gemma3:12b/kvm/1967814
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/gemma3:12b/kvm/1967814')
-rw-r--r--results/classifier/gemma3:12b/kvm/196781423
1 files changed, 23 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/kvm/1967814 b/results/classifier/gemma3:12b/kvm/1967814
new file mode 100644
index 000000000..a56ec88e2
--- /dev/null
+++ b/results/classifier/gemma3:12b/kvm/1967814
@@ -0,0 +1,23 @@
+
+Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having miscompares on disktests when there is a failed path.
+
+== Comment: #63 - Halil Pasic <email address hidden> - 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 <email address hidden> - 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.
\ No newline at end of file