Re: [Qemu-block] null-co undefined read behavior

[Fam Zheng]

On Mon, 06/12 17:20, John Snow wrote:
> I noticed while debugging an unrelated test that our use of the null
> driver has a habit of making functions like find_image_format trigger a
> lot of uninitialized memory errors in valgrind, because it will return a
> successful read without actually touching the buffer.
> 
> I see that in March there was a bit of a debate over whether or not the
> null driver SHOULD zero-write memory for performance reasons, but when
> this option isn't specified, the semantics of read are arguably broken.
> 
> This isn't terribly important to fix, but for actual debugging purposes
> it's nice to not have valgrind screaming at you with spurious junk. A
> few options:
> 
> (1) Admit that it's weird to allow reads to succeed with null-co driver.
> Annoy people who apparently wanted performance for their do-nothing
> driver and force the initialization of memory.
> 
> --or--
> 
> (1a) Use valgrind macros to pretend the memory has been initialized.

I assume this macro be used in find_image_format? Not great.

> 
> (2) Band-aid find_image_format to zero-initialize memory. Wonder if
> there are other usages of read() getting called from tests that utilize
> null-co that will make debugging difficult in other contexts.

I don't think there are many places in QEMU code where the buffer returned by
null-co is inspected, so this may be feasible. Test code that read the buffer
should already initialize the buffer, or use zero option.

> 
> (3) Edit any tests to always use the zero option when using the null
> driver, and then periodically keep updating this option in a losing
> battle over time.
> 
> (4) Find a way to adjust return value of null-co's read implementation
> to return 0 instead of a lie over the number of bytes it read/wrote.
> Correctly represents "No bytes written, but no error occurred either."

This is going to break a lot of things, I'm afraid.

Another option is making null always zero the first sectors.

Fam