All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: devel@driverdev.osuosl.org,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Avraham Shukron <avraham.shukron@gmail.com>,
	Alan Cox <alan@linux.intel.com>
Subject: Re: [PATCH 12/18] media: staging: atomisp: avoid a warning if 32 bits build
Date: Wed, 28 Mar 2018 11:34:56 -0300	[thread overview]
Message-ID: <20180328113448.51421aac@vento.lan> (raw)
In-Reply-To: <20180328141329.6nhx5qcaigqwz25d@mwanda>

Em Wed, 28 Mar 2018 17:13:29 +0300
Dan Carpenter <dan.carpenter@oracle.com> escreveu:

> On Mon, Mar 26, 2018 at 05:10:45PM -0400, Mauro Carvalho Chehab wrote:
> > Checking if a size_t value is bigger than ULONG_INT only makes
> > sense if building on 64 bits, as warned by:
> > 	drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:697 gmin_get_config_var() warn: impossible condition '(*out_len > (~0)) => (0-u32max > u32max)'
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > ---
> >  .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c    | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> > index be0c5e11e86b..3283c1b05d6a 100644
> > --- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> > +++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
> > @@ -693,9 +693,11 @@ static int gmin_get_config_var(struct device *dev, const char *var,
> >  	for (i = 0; i < sizeof(var8) && var8[i]; i++)
> >  		var16[i] = var8[i];
> >  
> > +#ifdef CONFIG_64BIT
> >  	/* To avoid owerflows when calling the efivar API */
> >  	if (*out_len > ULONG_MAX)
> >  		return -EINVAL;
> > +#endif  
> 
> I should just silence this particular warning in Smatch.  I feel like
> this is a pretty common thing and the ifdefs aren't very pretty.  :(

Smatch actually warned about a real thing here: atomisp is
doing a check in 32bits that it is always true. So, IMO,
something is needed to prevent 32bits extra useless code somehow,
perhaps via some EFI-var specific function that would do nothing
on 32 bits.

That's the first time I noticed this code on media (although I might
have missed something), so I guess this kind of checking is actually
not that common.

Regards,
Mauro

  reply	other threads:[~2018-03-28 14:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 21:10 [PATCH 01/18] media: r820t: don't crash if attach fails Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 02/18] media: staging: atomisp: do some coding style improvements Mauro Carvalho Chehab
2018-04-04 10:59   ` Sakari Ailus
2018-03-26 21:10 ` [PATCH 03/18] media: staging: atomisp: ia_css_output.host: don't use var before check Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 04/18] media: staging atomisp: declare static vars as such Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 05/18] media: staging: atomisp: get rid of stupid statements Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 06/18] media: staging: atomisp: add a missing include Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 07/18] media: staging: atomisp: fix endianess issues Mauro Carvalho Chehab
2018-03-27 11:02   ` Andy Shevchenko
2018-03-28  9:25     ` Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 08/18] media: staging: atomisp: remove unused set_pd_base() Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 09/18] media: staging: atomisp: get rid of an unused function Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 10/18] media: staging: atomisp: Get rid of *default.host.[ch] Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 11/18] media: staging: atomisp: don't access a NULL var Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 12/18] media: staging: atomisp: avoid a warning if 32 bits build Mauro Carvalho Chehab
2018-03-28 14:13   ` Dan Carpenter
2018-03-28 14:34     ` Mauro Carvalho Chehab [this message]
2018-03-26 21:10 ` [PATCH 13/18] media: staging: atomisp: remove an useless check Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 14/18] media: staging: atomisp: use %p to print pointers Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 15/18] media: staging: atomisp: get rid of some static warnings Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 16/18] media: staging: atomisp: stop mixing enum types Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 17/18] media: staging: atomisp: get rid of an unused var Mauro Carvalho Chehab
2018-03-26 21:10 ` [PATCH 18/18] media: staging: atomisp: stop duplicating input format types Mauro Carvalho Chehab

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=20180328113448.51421aac@vento.lan \
    --to=mchehab@s-opensource.com \
    --cc=alan@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=avraham.shukron@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=sakari.ailus@linux.intel.com \
    /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.