On Wed, 14 Feb 2024 12:30:19 +0100,
Michael S. Tsirkin wrote:
>>
>> On Wed, Feb 14, 2024 at 09:08:26AM +0000, Aiswarya Cyriac wrote:
>> > Hi Michael,
>> >
>> > Thank you for reviewing. I have updated my response inline
>> >
>> > On Tue, Feb 13, 2024 at 09:51:30AM +0100, Aiswarya Cyriac wrote:
>> > >> Fix the following warning when building virtio_snd driver.
>> > >>
>> > >> "
>> > >> *** CID 1583619: Uninitialized variables (UNINIT)
>> > >> sound/virtio/virtio_kctl.c:294 in virtsnd_kctl_tlv_op()
>> > >> 288
>> > >> 289 break;
>> > >> 290 }
>> > >> 291
>> > >> 292 kfree(tlv);
>> > >> 293
>> > >> vvv CID 1583619: Uninitialized variables (UNINIT)
>> > >> vvv Using uninitialized value "rc".
>> > >> 294 return rc;
>> > >> 295 }
>> > >> 296
>> > >> 297 /**
>> > >> 298 * virtsnd_kctl_get_enum_items() - Query items for the ENUMERATED element type.
>> > >> 299 * @snd: VirtIO sound device.
>> > >> "
>> > >>
>> > >> Signed-off-by: Anton Yakovlev <anton.yakovlev@xxxxxxxxxxxxxxx>
>> > >> Signed-off-by: Aiswarya Cyriac <aiswarya.cyriac@xxxxxxxxxxxxxxx>
>> > >> Reported-by: coverity-bot <keescook+coverity-bot@xxxxxxxxxxxx>
>> > >> Addresses-Coverity-ID: 1583619 ("Uninitialized variables")
>> > >> Fixes: d6568e3de42d ("ALSA: virtio: add support for audio controls")
>> >
>> > >I don't know enough about ALSA to say whether the patch is correct. But
>> > >the commit log needs work: please, do not "fix warnings" - analyse the
>> > >code and explain whether there is a real issue and if yes what is it
>> > >and how it can trigger. Is an invalid op_flag ever passed?
>> > >If it's just a coverity false positive it might be ok to
>> > >work around that but document this.
>> >
>> > This warning is caused by the absence of the "default" branch in the
>> > switch-block, and is a false positive because the kernel calls
>> > virtsnd_kctl_tlv_op() only with values for op_flag processed in
>> > this block.
>>
>> Well we don't normally have functions validate inputs.
>> In this case I am not really sure we should bother
>> with adding dead code. If you really want to, add BUG_ON.
> Please don't use BUG_ON() in such a case...
> There is no reason to break the whole operation.
How about adding a WARN_ON() on default case?
