Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Xiaomeng Tong <xiam0nd.tong@gmail.com>
To:     dan.carpenter@oracle.com
Cc:     elder@kernel.org, gregkh@linuxfoundation.org,
        greybus-dev@lists.linaro.org, johan@kernel.org,
        linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev,
        mgreer@animalcreek.com, stable@vger.kernel.org,
        vaibhav.sr@gmail.com, xiam0nd.tong@gmail.com
Subject: Re: [PATCH] greybus: audio_codec: fix three missing initializers for data
Date:   Tue, 29 Mar 2022 10:03:57 +0800
Message-Id: <20220329020357.10597-1-xiam0nd.tong@gmail.com>
In-Reply-To: <20220328141944.GT3293@kadam>
References: <20220328141944.GT3293@kadam>
Precedence: bulk

On Mon, 28 Mar 2022 17:19:45 +0300, Dan Carpenter wrote:
> On Sun, Mar 27, 2022 at 02:01:20PM +0800, Xiaomeng Tong wrote:
> > These three bugs are here:
> > 	struct gbaudio_data_connection *data;
> > 
> > If the list '&codec->module_list' is empty then the 'data' will
> > keep unchanged.
> 
> All three of these functions check for if the codec->module_list is
> empty at the start of the function so these are not real bugs.
> 
> Smatch is supposed to be able to figure this out, but apparently that
> code is broken so Smatch still prints a warning.  :(
> 
> Apparently GCC does not print a warning for this.  Even when I delete
> the check for list_empty() then GCC does not print a warning.  GCC often
> assumes that we enter loops one time.  I haven't looked at that, but I
> have noticed it in reviewing Smatch vs GCC warnings.
> 
> Generally we do not apply static checker work arounds.
> 
> I do not have a problem with this particular work around, but it needs
> an updated commit message which says it is just to silence static
> checker warnings and not to fix bugs.  Remove the Fixes tag.  Don't CC
> stable.

Yes, you are right. I have resend a PATCH with updated commit message as
you suggested, and cc you. Thank you.

--
Xiaomeng Tong