All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Johannes Tenschert <Johannes.Tenschert@informatik.stud.uni-erlangen.de>
Cc: devel@linuxdriverproject.org, gregkh@suse.de,
	Jon Brenner <jbrenner@taosinc.com>,
	Jonathan Cameron <jic23@cam.ac.uk>,
	linux-iio@vger.kernel.org
Subject: Re: [PATCH 2/2] staging: iio: light: tsl2583.c: obsolete use of strict_strtoul
Date: Mon, 12 Dec 2011 21:55:13 +0300	[thread overview]
Message-ID: <20111212185513.GD3503@mwanda> (raw)
In-Reply-To: <1323700503-30053-2-git-send-email-Johannes.Tenschert@informatik.stud.uni-erlangen.de>

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

These patches need to be CC'd to the iio mailing list, and Jonathan
Cameron as well.  Use the ./scripts/get_maintainer.pl script for
hints who should be CC'd.

On Mon, Dec 12, 2011 at 03:35:03PM +0100, Johannes Tenschert wrote:
> @@ -621,7 +621,7 @@ static ssize_t taos_als_trim_store(struct device *dev,
>  	struct tsl2583_chip *chip = iio_priv(indio_dev);
>  	unsigned long value;
>  
> -	if (strict_strtoul(buf, 0, &value))
> +	if (kstrtoul(buf, 0, &value))
>  		return -EINVAL;
>  
>  	if (value)

We save value to
	chip->taos_settings.als_gain_trim = value;
als_gain_trim is an int, so on a 64bit system this would truncate
the high bits away and we could get a zero where we don't expect
one.

I don't think it's a problem, but looking at how als_gain_trim is
used, I noticed this potential bug:

   362          lux_val = taos_get_lux(indio_dev);
                ^^^^^^^
lux_val can be zero under certain circumstances.

   363          if (lux_val < 0) {
   364                  dev_err(&chip->client->dev, "taos_als_calibrate failed to get lux\n");
   365                  return lux_val;
   366          }
   367          gain_trim_val = (unsigned int) (((chip->taos_settings.als_cal_target)
   368                          * chip->taos_settings.als_gain_trim) / lux_val);
                                                                     ^^^^^^^^^
leading to a divide by zero bug.

   369  
   370          if ((gain_trim_val < 250) || (gain_trim_val > 4000)) {
   371                  dev_err(&chip->client->dev,
   372                          "taos_als_calibrate failed: trim_val of %d is out of range\n",
   373                          gain_trim_val);
   374                  return -ENODATA;
   375          }
   376          chip->taos_settings.als_gain_trim = (int) gain_trim_val;


Also I don't understand why als_gain_trim isn't unsigned.  So
basically I think we should make it unsigned and I think we should
use kstrtouint() here.  Also instead of returning -EINVAL, we
should preserve the return code from kstrtoul() and return that.
But I don't know the code that well so I may have missed something.

The other divide by zero bug should be fixed in a different patch.

regards,
dan carpenter

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

           reply	other threads:[~2011-12-12 18:55 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <1323700503-30053-2-git-send-email-Johannes.Tenschert@informatik.stud.uni-erlangen.de>]

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=20111212185513.GD3503@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=Johannes.Tenschert@informatik.stud.uni-erlangen.de \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@suse.de \
    --cc=jbrenner@taosinc.com \
    --cc=jic23@cam.ac.uk \
    --cc=linux-iio@vger.kernel.org \
    /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.