[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170601164019.0a4035a4@endymion>
Date: Thu, 1 Jun 2017 16:40:19 +0200
From: Jean Delvare <jdelvare@...e.de>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH] firmware: dmi: Check DMI structure length
Hi Andy,
Thanks for the review.
On Thu, 1 Jun 2017 16:16:05 +0300, Andy Shevchenko wrote:
> On Thu, Jun 1, 2017 at 4:08 PM, Jean Delvare <jdelvare@...e.de> wrote:
> > Before accessing DMI data to record it for later, we should ensure
> > that the DMI structures are large enough to contain the data in
> > question.
>
> > - const u8 *d = (u8 *) dm + index;
> > + const u8 *d;
>
> > + d = (u8 *) dm + index;
>
> I think you may leave this as is and make it compiler's burden to optimize.
Is there any benefit except making the patch smaller?
> > - const u8 *d = (u8 *) dm + index;
> > + const u8 *d;
>
> > + d = (u8 *) dm + index;
>
> Ditto.
>
> > - int i, count = *(u8 *)(dm + 1);
> > + int i, count;
>
> > + count = *(u8 *)(dm + 1);
>
> Ditto.
I would expect a static code analyzer to complain about at least the
last one. Dereferencing a pointer before checking its validity is bad.
I'm not a big fan of counting of compiler optimizations to make the
code right.
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists