1 files changed, 121 insertions, 0 deletions
diff --git a/results/classifier/118/none/1798780 b/results/classifier/118/none/1798780
new file mode 100644
index 00000000..85121faa
--- /dev/null
+++ b/results/classifier/118/none/1798780
@@ -0,0 +1,121 @@
+user-level: 0.526
+hypervisor: 0.480
+semantic: 0.468
+permissions: 0.459
+TCG: 0.437
+graphic: 0.416
+PID: 0.414
+virtual: 0.410
+debug: 0.402
+peripherals: 0.400
+VMM: 0.394
+performance: 0.384
+vnc: 0.381
+ppc: 0.375
+register: 0.363
+architecture: 0.351
+KVM: 0.329
+kernel: 0.328
+device: 0.322
+assembly: 0.309
+arm: 0.303
+boot: 0.301
+files: 0.282
+network: 0.278
+x86: 0.271
+socket: 0.268
+i386: 0.266
+risc-v: 0.258
+mistranslation: 0.227
+
+hw/usb/dev-mtp.c:1616: bad test ?
+
+hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively exhaustive tests is always true [-Wlogical-op]
+
+Source code is
+
+                if ((ret == -1) && (errno != EINTR || errno != EAGAIN ||
+                                    errno != EWOULDBLOCK)) {
+
+Maybe better code
+
+                if ((ret == -1) && (errno != EINTR && errno != EAGAIN &&
+                                    errno != EWOULDBLOCK)) {
+
+On Fri, 19 Oct 2018 at 10:22, dcb <email address hidden> wrote:
+> hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively
+> exhaustive tests is always true [-Wlogical-op]
+>
+> Source code is
+>
+>                 if ((ret == -1) && (errno != EINTR || errno != EAGAIN ||
+>                                     errno != EWOULDBLOCK)) {
+>
+> Maybe better code
+>
+>                 if ((ret == -1) && (errno != EINTR && errno != EAGAIN &&
+>                                     errno != EWOULDBLOCK)) {
+
+Hi Gerd, Bandan -- I was going through older launchpad bugs and
+noticed that this one about a dubious conditional in dev-mtp.c is
+still unfixed.
+
+Is the file descriptor being used here one that's in non-blocking
+mode? If so, then busy-waiting in a loop while the write() returns
+EWOULDBLOCK is probably not what you wanted. If it's not then
+there's no need to check for EAGAIN or EWOULDBLOCK, I think.
+Consider using qemu_write_full() instead of open-coding
+the retry loop ?
+
+thanks
+-- PMM
+
+
+On Tue, Jan 22, 2019 at 07:41:16AM -0500, Bandan Das wrote:
+> 
+> qemu_write_full takes care of partial blocking writes,
+> as in cases of larger file sizes
+> 
+> Suggested-by: Peter Maydell <email address hidden>
+> Signed-off-by: Bandan <email address hidden>
+
+Hmm, doesn't apply, and git fails to do a 3way merge too due to unknown
+sha1.
+
+cheers,
+  Gerd
+
+
+
+On Thu, Jan 24, 2019 at 03:19:03AM -0500, Bandan Das wrote:
+> Gerd Hoffmann <email address hidden> writes:
+> 
+> > On Tue, Jan 22, 2019 at 07:41:16AM -0500, Bandan Das wrote:
+> >> 
+> >> qemu_write_full takes care of partial blocking writes,
+> >> as in cases of larger file sizes
+> >> 
+> >> Suggested-by: Peter Maydell <email address hidden>
+> >> Signed-off-by: Bandan <email address hidden>
+> >
+> > Hmm, doesn't apply, and git fails to do a 3way merge too due to unknown
+> > sha1.
+> 
+> Oops, sorry, I realize now this is on top of the write buffer breakup patches.
+
+Hmm, they are queued up already, so that should have worked.
+
+> Should I resend a v2 on top of master and send a v3 for the write buffer breakup
+> patches ?
+
+Can you just send a single series with both this fix and the breakup
+patches, against latest master?
+
+thanks,
+  Gerd
+
+
+
+Fixed by commit 49f9e8d660d4 which will be in QEMU 4.0.
+
+