All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Hartmut Knaack <knaack.h@gmx.de>,
	Peter Meerwald <pmeerw@pmeerw.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: iio: ad5933: avoid uninitialized variable in error case
Date: Sat, 30 Jan 2016 14:18:10 +0000	[thread overview]
Message-ID: <56ACC622.8000908@kernel.org> (raw)
In-Reply-To: <1453737099-1959671-1-git-send-email-arnd@arndb.de>

On 25/01/16 15:50, Arnd Bergmann wrote:
> The ad5933_i2c_read function returns an error code to indicate
> whether it could read data or not. However ad5933_work() ignores
> this return code and just accesses the data unconditionally,
> which gets detected by gcc as a possible bug:
> 
> drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work':
> drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This adds minimal error handling so we only evaluate the
> data if it was correctly read.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hi Arnd,

Thanks for the patch.   The handling in here is a little fiddly
by the look of things. Lars can you take a look at this when
you have a minute?

At a very high level, it doesn't make sense to fix this instance and
not the one in the context of the patch below.
See below...
> ---
>  drivers/staging/iio/impedance-analyzer/ad5933.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index 10c43dda0f5a..304bb464e478 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -647,6 +647,7 @@ static void ad5933_work(struct work_struct *work)
>  	__be16 buf[2];
>  	int val[2];
>  	unsigned char status;
> +	int ret;
>  
>  	mutex_lock(&indio_dev->mlock);
>  	if (st->state == AD5933_CTRL_INIT_START_FREQ) {
> @@ -658,9 +659,9 @@ static void ad5933_work(struct work_struct *work)
>  		return;
>  	}
>  
> -	ad5933_i2c_read(st->client, AD5933_REG_STATUS, 1, &status);
> +	ret = ad5933_i2c_read(st->client, AD5933_REG_STATUS, 1, &status);
>  
> -	if (status & AD5933_STAT_DATA_VALID) {
> +	if (!ret && (status & AD5933_STAT_DATA_VALID)) {
The else is non trivial here as it assumes we will get the data later. If we
get such a failure, we probably want to drop out completely rather than paper
over the gaps..
>  		int scan_count = bitmap_weight(indio_dev->active_scan_mask,
>  					       indio_dev->masklength);
Same issue on the next line - this results in known garbage data being spooled
out.
>  		ad5933_i2c_read(st->client,
> 


WARNING: multiple messages have this Message-ID (diff)
From: jic23@kernel.org (Jonathan Cameron)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] staging: iio: ad5933: avoid uninitialized variable in error case
Date: Sat, 30 Jan 2016 14:18:10 +0000	[thread overview]
Message-ID: <56ACC622.8000908@kernel.org> (raw)
In-Reply-To: <1453737099-1959671-1-git-send-email-arnd@arndb.de>

On 25/01/16 15:50, Arnd Bergmann wrote:
> The ad5933_i2c_read function returns an error code to indicate
> whether it could read data or not. However ad5933_work() ignores
> this return code and just accesses the data unconditionally,
> which gets detected by gcc as a possible bug:
> 
> drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work':
> drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This adds minimal error handling so we only evaluate the
> data if it was correctly read.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hi Arnd,

Thanks for the patch.   The handling in here is a little fiddly
by the look of things. Lars can you take a look at this when
you have a minute?

At a very high level, it doesn't make sense to fix this instance and
not the one in the context of the patch below.
See below...
> ---
>  drivers/staging/iio/impedance-analyzer/ad5933.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index 10c43dda0f5a..304bb464e478 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -647,6 +647,7 @@ static void ad5933_work(struct work_struct *work)
>  	__be16 buf[2];
>  	int val[2];
>  	unsigned char status;
> +	int ret;
>  
>  	mutex_lock(&indio_dev->mlock);
>  	if (st->state == AD5933_CTRL_INIT_START_FREQ) {
> @@ -658,9 +659,9 @@ static void ad5933_work(struct work_struct *work)
>  		return;
>  	}
>  
> -	ad5933_i2c_read(st->client, AD5933_REG_STATUS, 1, &status);
> +	ret = ad5933_i2c_read(st->client, AD5933_REG_STATUS, 1, &status);
>  
> -	if (status & AD5933_STAT_DATA_VALID) {
> +	if (!ret && (status & AD5933_STAT_DATA_VALID)) {
The else is non trivial here as it assumes we will get the data later. If we
get such a failure, we probably want to drop out completely rather than paper
over the gaps..
>  		int scan_count = bitmap_weight(indio_dev->active_scan_mask,
>  					       indio_dev->masklength);
Same issue on the next line - this results in known garbage data being spooled
out.
>  		ad5933_i2c_read(st->client,
> 

  reply	other threads:[~2016-01-30 14:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25 15:50 [PATCH] staging: iio: ad5933: avoid uninitialized variable in error case Arnd Bergmann
2016-01-25 15:50 ` Arnd Bergmann
2016-01-30 14:18 ` Jonathan Cameron [this message]
2016-01-30 14:18   ` Jonathan Cameron
2016-01-30 15:06   ` Lars-Peter Clausen
2016-01-30 15:06     ` Lars-Peter Clausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56ACC622.8000908@kernel.org \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=arnd@arndb.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.