BMidiLocalProducer::SprayData KDLs when passing a buffer that's too big for a single MIDI message

[nilsding]

Backstory: I was hacking on ​QMidi a bit until I reached the part of adding my changes to the Haiku portion of the library, where I observed that sending a ProgramChange MIDI message results in a KDL almost immediately.

Out of curiosity, I dug down deeper and added some more debugging printfs to the usb_midi driver (see also: additional-usb_midi-logs.patch).
Looking at the debug output (full kernel output attached as haiku.log) it became obvious to me that the xfer_bytes variable underflows (as it tries to transmit 3 bytes for a message that which requires 2), and therefore the memset that occurs in the most inner loop of usb_midi_write causes a page fault at some region in memory.

I then adapted the call to BMidiLocalProducer::SprayData to set a buffer size of 2 for the ProgramChange (0xC0) message, and 3 otherwise (it would still KDL on ChannelPressure 0xD0 ones). With that in place the usb_midi driver no longer causes a KDL, but I reckon it should not cause a KDL in first place, regardless of the buffer size.

I have attached a small(-ish ;-)) re-production program which reuses some of the code found in the Haiku part of QMidi. Read the header comment of midi_kdl_repro.cpp for compile instructions.

Tried this on hrev53636 x86, but I assume this bug appears on other platforms as well.

[nilsding]

haiku.log

[nilsding]

additional log statements for usb_midi

[nilsding]

testing program that causes a KDL

[korli]

see ​https://review.haiku-os.org/c/haiku/+/2048

[korli]

in the view of the driver this program tries to send a buffer of two packets, the second one being truncated. maybe it would be simpler to avoid sending such truncated packets.

[korli]

Fix applied in hrev54135 Please check with hrev54135 or newer.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone