Received-SPF: pass (google.com: domain of linux-kernel+bounces-65259-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 14 Feb 2024 14:16:45 +0100
Message-ID: <87v86rgp8i.wl-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Aiswarya Cyriac <Aiswarya.Cyriac@opensynergy.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"perex@perex.cz"
	<perex@perex.cz>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"virtio-dev@lists.oasis-open.org" <virtio-dev@lists.oasis-open.org>,
	Anton
 Yakovlev <Anton.Yakovlev@opensynergy.com>,
	coverity-bot
	<keescook+coverity-bot@chromium.org>,
	Mikhail Golubev-Ciuchea
	<Mikhail.Golubev-Ciuchea@opensynergy.com>
Subject: Re: [PATCH] ALSA: virtio: Fix "Coverity: virtsnd_kctl_tlv_op(): Uninitialized variables" warning.
In-Reply-To: <FR3P281MB2527A0498C3B1E3899087028E64E2@FR3P281MB2527.DEUP281.PROD.OUTLOOK.COM>
References: <20240213085131.503569-1-aiswarya.cyriac@opensynergy.com>
	<20240213035806-mutt-send-email-mst@kernel.org>
	<FR3P281MB25272BA9CC886E270EEAE380E64E2@FR3P281MB2527.DEUP281.PROD.OUTLOOK.COM>
	<20240214062348-mutt-send-email-mst@kernel.org>
	<871q9fi8dw.wl-tiwai@suse.de>
	<FR3P281MB2527A0498C3B1E3899087028E64E2@FR3P281MB2527.DEUP281.PROD.OUTLOOK.COM>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
Precedence: bulk
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Wed, 14 Feb 2024 14:07:40 +0100,
Aiswarya Cyriac wrote:
> 
> 
> 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@opensynergy.com>
> >> > >> Signed-off-by: Aiswarya Cyriac <aiswarya.cyriac@opensynergy.com>
> >> > >> Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
> >> > >> 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?

That's better :)


thanks,

Takashi