From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized Date: Sun, 13 Nov 2016 09:47:41 +0100 Message-ID: <20161113084741.GA5225@kroah.com> References: <20161110164454.293477-1-arnd@arndb.de> <2695221.kyRJMsRMjs@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Arnd Bergmann , Linus Torvalds , Srinivas Kandagatla , sayli karnik , Mark Brown , Andrew Morton , Anna Schumaker , "David S. Miller" , Herbert Xu , Ilya Dryomov , Javier Martinez Canillas , Jiri Kosina , Ley Foon Tan , "Luis R . Rodriguez" , Martin Schwidefsky , Mauro Carvalho Chehab , Michal Marek , Russell King , Sean Young Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kbuild-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Sat, Nov 12, 2016 at 01:27:12PM +0000, Jonathan Cameron wrote: > On 11/11/16 19:49, Arnd Bergmann wrote: > > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote: > >> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote: > >>> > >>> Please merge these directly if you are happy with the result. > >> > >> I will take this. > > > > Thanks a lot! > > > >> I do see two warnings, but they both seem to be valid and recent, > >> though, so I have no issues with the spurious cases. > > > > Ok, both of them should have my fixes coming your way already. > > > >> Warning #1: > >> > >> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’: > >> sound/soc/qcom/lpass-platform.c:83:29: warning: ‘dma_ch’ may be used > >> uninitialized in this function [-Wmaybe-uninitialized] > >> drvdata->substream[dma_ch] = substream; > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ > >> > >> and 'dma_ch' usage there really is crazy and wrong. Broken by > >> 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage") > > > > Right, the patches crossed here, the bugfix patch that introduced > > this came into linux-next over the kernel summit, and the fix I > > sent on Tuesday made it into Mark Brown's tree on Wednesday but not > > before you pulled alsa tree. It should be fixed the next time you > > pull from the alsa tree, the commit is > > > > 3b89e4b77ef9 ("ASoC: lpass-platform: initialize dma channel number") > > > >> Warning #2 is not a real bug, but it's reasonable that gcc doesn't > >> know that storage_bytes (chip->read_size) has to be 2/4. Again, > >> introduced recently by commit 231147ee77f3 ("iio: maxim_thermocouple: > >> Align 16 bit big endian value of raw reads"), so you didn't see it. > > > > This is the one I mentioned in the commit message as one that > > is fixed in linux-next and that should make it in soon. > > > >> drivers/iio/temperature/maxim_thermocouple.c: In function > >> ‘maxim_thermocouple_read_raw’: > >> drivers/iio/temperature/maxim_thermocouple.c:141:5: warning: ‘ret’ > >> may be used uninitialized in this function [-Wmaybe-uninitialized] > >> if (ret) > >> ^ > >> drivers/iio/temperature/maxim_thermocouple.c:128:6: note: ‘ret’ was > >> declared here > >> int ret; > >> ^~~ > >> > >> and I guess that code can just initialize 'ret' to '-EINVAL' or > >> something to just make the theoretical "somehow we had a wrong > >> chip->read_size" case error out cleanly. > > > > Right, that was my conclusion too. I sent the bugfix on Oct 25 > > for linux-next but it didn't make it in until this Monday, after > > you pulled the patch that introduced it on Oct 29. > > > > The commit in staging-testing is > > 32cb7d27e65d ("iio: maxim_thermocouple: detect invalid storage size in read()") > > > > Greg and Jonathan, I see now that this is part of the 'iio-for-4.10b' > > branch, so I suspect you were not planning to send this before the > > merge window. Could you make sure this ends up in v4.9 so we get > > a clean build when -Wmaybe-uninitialized gets enabled again? > I'll queue this up and send a pull to Greg tomorrow. > > Was highly doubtful that a false warning suppression (be it an > understandable one) was worth sending mid cycle, hence it was > taking the slow route. I can just cherry-pick this, no need to send a separate pull request. greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932954AbcKMIrg (ORCPT ); Sun, 13 Nov 2016 03:47:36 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:33712 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932239AbcKMIrd (ORCPT ); Sun, 13 Nov 2016 03:47:33 -0500 Date: Sun, 13 Nov 2016 09:47:41 +0100 From: Greg KH To: Jonathan Cameron Cc: Arnd Bergmann , Linus Torvalds , Srinivas Kandagatla , sayli karnik , Mark Brown , Andrew Morton , Anna Schumaker , "David S. Miller" , Herbert Xu , Ilya Dryomov , Javier Martinez Canillas , Jiri Kosina , Ley Foon Tan , "Luis R . Rodriguez" , Martin Schwidefsky , Mauro Carvalho Chehab , Michal Marek , Russell King , Sean Young , Sebastian Ott , Trond Myklebust , the arch/x86 maintainers , Linux Kbuild mailing list , Linux Kernel Mailing List , arcml , nios2-dev@lists.rocketboards.org, linux-s390 , Linux Crypto Mailing List , Linux Media Mailing List , Linux NFS Mailing List Subject: Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized Message-ID: <20161113084741.GA5225@kroah.com> References: <20161110164454.293477-1-arnd@arndb.de> <2695221.kyRJMsRMjs@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 12, 2016 at 01:27:12PM +0000, Jonathan Cameron wrote: > On 11/11/16 19:49, Arnd Bergmann wrote: > > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote: > >> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote: > >>> > >>> Please merge these directly if you are happy with the result. > >> > >> I will take this. > > > > Thanks a lot! > > > >> I do see two warnings, but they both seem to be valid and recent, > >> though, so I have no issues with the spurious cases. > > > > Ok, both of them should have my fixes coming your way already. > > > >> Warning #1: > >> > >> sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’: > >> sound/soc/qcom/lpass-platform.c:83:29: warning: ‘dma_ch’ may be used > >> uninitialized in this function [-Wmaybe-uninitialized] > >> drvdata->substream[dma_ch] = substream; > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ > >> > >> and 'dma_ch' usage there really is crazy and wrong. Broken by > >> 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage") > > > > Right, the patches crossed here, the bugfix patch that introduced > > this came into linux-next over the kernel summit, and the fix I > > sent on Tuesday made it into Mark Brown's tree on Wednesday but not > > before you pulled alsa tree. It should be fixed the next time you > > pull from the alsa tree, the commit is > > > > 3b89e4b77ef9 ("ASoC: lpass-platform: initialize dma channel number") > > > >> Warning #2 is not a real bug, but it's reasonable that gcc doesn't > >> know that storage_bytes (chip->read_size) has to be 2/4. Again, > >> introduced recently by commit 231147ee77f3 ("iio: maxim_thermocouple: > >> Align 16 bit big endian value of raw reads"), so you didn't see it. > > > > This is the one I mentioned in the commit message as one that > > is fixed in linux-next and that should make it in soon. > > > >> drivers/iio/temperature/maxim_thermocouple.c: In function > >> ‘maxim_thermocouple_read_raw’: > >> drivers/iio/temperature/maxim_thermocouple.c:141:5: warning: ‘ret’ > >> may be used uninitialized in this function [-Wmaybe-uninitialized] > >> if (ret) > >> ^ > >> drivers/iio/temperature/maxim_thermocouple.c:128:6: note: ‘ret’ was > >> declared here > >> int ret; > >> ^~~ > >> > >> and I guess that code can just initialize 'ret' to '-EINVAL' or > >> something to just make the theoretical "somehow we had a wrong > >> chip->read_size" case error out cleanly. > > > > Right, that was my conclusion too. I sent the bugfix on Oct 25 > > for linux-next but it didn't make it in until this Monday, after > > you pulled the patch that introduced it on Oct 29. > > > > The commit in staging-testing is > > 32cb7d27e65d ("iio: maxim_thermocouple: detect invalid storage size in read()") > > > > Greg and Jonathan, I see now that this is part of the 'iio-for-4.10b' > > branch, so I suspect you were not planning to send this before the > > merge window. Could you make sure this ends up in v4.9 so we get > > a clean build when -Wmaybe-uninitialized gets enabled again? > I'll queue this up and send a pull to Greg tomorrow. > > Was highly doubtful that a false warning suppression (be it an > understandable one) was worth sending mid cycle, hence it was > taking the slow route. I can just cherry-pick this, no need to send a separate pull request. greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 From: gregkh@linuxfoundation.org (Greg KH) Date: Sun, 13 Nov 2016 09:47:41 +0100 Subject: [PATCH v2 00/11] getting back -Wmaybe-uninitialized In-Reply-To: References: <20161110164454.293477-1-arnd@arndb.de> <2695221.kyRJMsRMjs@wuerfel> List-ID: Message-ID: <20161113084741.GA5225@kroah.com> To: linux-snps-arc@lists.infradead.org On Sat, Nov 12, 2016@01:27:12PM +0000, Jonathan Cameron wrote: > On 11/11/16 19:49, Arnd Bergmann wrote: > > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote: > >> On Thu, Nov 10, 2016@8:44 AM, Arnd Bergmann wrote: > >>> > >>> Please merge these directly if you are happy with the result. > >> > >> I will take this. > > > > Thanks a lot! > > > >> I do see two warnings, but they both seem to be valid and recent, > >> though, so I have no issues with the spurious cases. > > > > Ok, both of them should have my fixes coming your way already. > > > >> Warning #1: > >> > >> sound/soc/qcom/lpass-platform.c: In function ?lpass_platform_pcmops_open?: > >> sound/soc/qcom/lpass-platform.c:83:29: warning: ?dma_ch? may be used > >> uninitialized in this function [-Wmaybe-uninitialized] > >> drvdata->substream[dma_ch] = substream; > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ > >> > >> and 'dma_ch' usage there really is crazy and wrong. Broken by > >> 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage") > > > > Right, the patches crossed here, the bugfix patch that introduced > > this came into linux-next over the kernel summit, and the fix I > > sent on Tuesday made it into Mark Brown's tree on Wednesday but not > > before you pulled alsa tree. It should be fixed the next time you > > pull from the alsa tree, the commit is > > > > 3b89e4b77ef9 ("ASoC: lpass-platform: initialize dma channel number") > > > >> Warning #2 is not a real bug, but it's reasonable that gcc doesn't > >> know that storage_bytes (chip->read_size) has to be 2/4. Again, > >> introduced recently by commit 231147ee77f3 ("iio: maxim_thermocouple: > >> Align 16 bit big endian value of raw reads"), so you didn't see it. > > > > This is the one I mentioned in the commit message as one that > > is fixed in linux-next and that should make it in soon. > > > >> drivers/iio/temperature/maxim_thermocouple.c: In function > >> ?maxim_thermocouple_read_raw?: > >> drivers/iio/temperature/maxim_thermocouple.c:141:5: warning: ?ret? > >> may be used uninitialized in this function [-Wmaybe-uninitialized] > >> if (ret) > >> ^ > >> drivers/iio/temperature/maxim_thermocouple.c:128:6: note: ?ret? was > >> declared here > >> int ret; > >> ^~~ > >> > >> and I guess that code can just initialize 'ret' to '-EINVAL' or > >> something to just make the theoretical "somehow we had a wrong > >> chip->read_size" case error out cleanly. > > > > Right, that was my conclusion too. I sent the bugfix on Oct 25 > > for linux-next but it didn't make it in until this Monday, after > > you pulled the patch that introduced it on Oct 29. > > > > The commit in staging-testing is > > 32cb7d27e65d ("iio: maxim_thermocouple: detect invalid storage size in read()") > > > > Greg and Jonathan, I see now that this is part of the 'iio-for-4.10b' > > branch, so I suspect you were not planning to send this before the > > merge window. Could you make sure this ends up in v4.9 so we get > > a clean build when -Wmaybe-uninitialized gets enabled again? > I'll queue this up and send a pull to Greg tomorrow. > > Was highly doubtful that a false warning suppression (be it an > understandable one) was worth sending mid cycle, hence it was > taking the slow route. I can just cherry-pick this, no need to send a separate pull request. greg k-h