linux-kernel - Re: [PATCH v2] staging: vt6656: Use ARRAY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200324131830.GD4672@kadam>
Date:   Tue, 24 Mar 2020 16:18:30 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Quentin Deslandes <quentin.deslandes@...ev.co.uk>
Cc:     Oscar Carter <oscar.carter@....com>,
        Forest Bond <forest@...ttletooquiet.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Malcolm Priestley <tvboxspy@...il.com>,
        Colin Ian King <colin.king@...onical.com>,
        Gabriela Bittencourt <gabrielabittencourt00@...il.com>,
        devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] staging: vt6656: Use ARRAY_SIZE instead of hardcoded
 size

On Tue, Mar 24, 2020 at 09:54:56AM +0000, Quentin Deslandes wrote:
> On 03/18/20 18:40:15, Oscar Carter wrote:
> > Use ARRAY_SIZE to replace the hardcoded size so we will never have a
> > mismatch.
> > 
> > Signed-off-by: Oscar Carter <oscar.carter@....com>
> > ---
> > Changelog v1 -> v2
> > - Use ARRAY_SIZE(priv->cck_pwr_tbl) everywhere instead of introducing a new
> >   variable to hold its value.
> > 
> >  drivers/staging/vt6656/main_usb.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
> > index 5e48b3ddb94c..acfcc11c3b61 100644
> > --- a/drivers/staging/vt6656/main_usb.c
> > +++ b/drivers/staging/vt6656/main_usb.c
> > @@ -23,6 +23,7 @@
> > 
> >  #include <linux/etherdevice.h>
> >  #include <linux/file.h>
> > +#include <linux/kernel.h>
> >  #include "device.h"
> >  #include "card.h"
> >  #include "baseband.h"
> > @@ -145,7 +146,7 @@ static int vnt_init_registers(struct vnt_private *priv)
> > 
> >  	init_cmd->init_class = DEVICE_INIT_COLD;
> >  	init_cmd->exist_sw_net_addr = priv->exist_sw_net_addr;
> > -	for (ii = 0; ii < 6; ii++)
> > +	for (ii = 0; ii < ARRAY_SIZE(init_cmd->sw_net_addr); ii++)
> >  		init_cmd->sw_net_addr[ii] = priv->current_net_addr[ii];
> >  	init_cmd->short_retry_limit = priv->short_retry_limit;
> >  	init_cmd->long_retry_limit = priv->long_retry_limit;
> > @@ -184,7 +185,7 @@ static int vnt_init_registers(struct vnt_private *priv)
> >  	priv->cck_pwr = priv->eeprom[EEP_OFS_PWR_CCK];
> >  	priv->ofdm_pwr_g = priv->eeprom[EEP_OFS_PWR_OFDMG];
> >  	/* load power table */
> > -	for (ii = 0; ii < 14; ii++) {
> > +	for (ii = 0; ii < ARRAY_SIZE(priv->cck_pwr_tbl); ii++) {
> >  		priv->cck_pwr_tbl[ii] =
> >  			priv->eeprom[ii + EEP_OFS_CCK_PWR_TBL];
> >  		if (priv->cck_pwr_tbl[ii] == 0)
> > @@ -200,7 +201,7 @@ static int vnt_init_registers(struct vnt_private *priv)
> >  	 * original zonetype is USA, but custom zonetype is Europe,
> >  	 * then need to recover 12, 13, 14 channels with 11 channel
> >  	 */
> > -	for (ii = 11; ii < 14; ii++) {
> > +	for (ii = 11; ii < ARRAY_SIZE(priv->cck_pwr_tbl); ii++) {
> >  		priv->cck_pwr_tbl[ii] = priv->cck_pwr_tbl[10];
> >  		priv->ofdm_pwr_tbl[ii] = priv->ofdm_pwr_tbl[10];
> >  	}
> > --
> > 2.20.1
> > 
> 
> Looks good, however are we certain priv->cck_pwr_tbl and
> priv->ofdm_pwr_tbl are always the same size?
> 
> What about using a macro for cck_pwr_tbl and ofdm_pwr_tbl size in
> device.h? Or a BUILD_BUG() if array's sizes are different? It could be
> helpful for future developers to say these arrays must be the same size.

That's a bit over engineering something which is pretty trivial.
Normally, we would just make the size a define instead of a magic number
14.

	u8 cck_pwr_tbl[14];
	u8 ofdm_pwr_tbl[14];
	u8 ofdm_a_pwr_tbl[42];

If people change the size in the future (unlikely) and it causes a bug
then they kind of deserve it because they need to ensure all the new
stuff is initialized, right?  If they change it and it results in a
buffer overflow then static checkers would complain.  If they changed it
and it resulted in uninitialized data being used then it would be zero
so that's okay.

So, yeah.  Ideally we would figure out a reason for the magic number 14
and create a define, but it's not strictly required.  This patch makes
the code better and doesn't introduce any problems that weren't already
there.

regards,
dan carpenter