All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <m.chehab@samsung.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Antti Palosaari <crope@iki.fi>
Subject: Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
Date: Sat, 02 Nov 2013 19:15:15 -0200	[thread overview]
Message-ID: <20131102191515.0af09112@samsung.com> (raw)
In-Reply-To: <5275357F.5090405@xs4all.nl>

Em Sat, 02 Nov 2013 18:25:19 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> Hi Mauro,
> 
> I'll review this series more carefully on Monday,

Thanks!

> but for now I want to make
> a suggestion for the array checks:
> 
> On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
> > Dynamic static allocation is evil, as Kernel stack is too low, and
> > compilation complains about it on some archs:
> > 
> > 	drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
> > 	drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
> > 	drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
> > 	drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > 	drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
> > 	drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > 	drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
> > 	drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
> > 
> > Instead, let's enforce a limit for the buffer. Considering that I2C
> > transfers are generally limited, and that devices used on USB has a
> > max data length of 80, it seem safe to use 80 as the hard limit for all
> > those devices. On most cases, the limit is a way lower than that, but
> > 80 is small enough to not affect the Kernel stack, and it is a no brain
> > limit, as using smaller ones would require to either carefully each
> > driver or to take a look on each datasheet.
> > 
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> > Cc: Antti Palosaari <crope@iki.fi>
> > ---
> >  drivers/media/tuners/e4000.c    | 18 ++++++++++++++++--
> >  drivers/media/tuners/fc2580.c   | 18 ++++++++++++++++--
> >  drivers/media/tuners/tda18212.c | 18 ++++++++++++++++--
> >  drivers/media/tuners/tda18218.c | 18 ++++++++++++++++--
> >  4 files changed, 64 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
> > index ad9309da4a91..235e90251609 100644
> > --- a/drivers/media/tuners/e4000.c
> > +++ b/drivers/media/tuners/e4000.c
> > @@ -24,7 +24,7 @@
> >  static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >  {
> >  	int ret;
> > -	u8 buf[1 + len];
> > +	u8 buf[80];
> >  	struct i2c_msg msg[1] = {
> >  		{
> >  			.addr = priv->cfg->i2c_addr,
> > @@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >  		}
> >  	};
> >  
> > +	if (1 + len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> 
> I think this can be greatly simplified to:
> 
> 	if (WARN_ON(len + 1 > sizeof(buf))
> 		return -EREMOTEIO;
> 
> This should really never happen, and it is a clear driver bug if it does. WARN_ON
> does the job IMHO.

Works for me. I'll wait for more comments, and go for it on v3.

>  I also don't like the EREMOTEIO error: it has nothing to do with
> an I/O problem. Wouldn't EMSGSIZE be much better here?


EMSGSIZE is not used yet at drivers/media. So, it is probably not the
right error code.

I remember that there's an error code for that on I2C (EOPNOTSUPP?).

In any case, I don't think we should use an unusual error code here.
In theory, this error should never happen, but we don't want to break
userspace because of it. That's why I opted to use EREMOTEIO: this is
the error code that most of those drivers return when something gets
wrong during I2C transfers.

> Ditto for all the similar situations in the patch series.
> 
> Regards,
> 
> 	Hans
> 
> >  	buf[0] = reg;
> >  	memcpy(&buf[1], val, len);
> >  
> > @@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >  static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >  {
> >  	int ret;
> > -	u8 buf[len];
> > +	u8 buf[80];
> >  	struct i2c_msg msg[2] = {
> >  		{
> >  			.addr = priv->cfg->i2c_addr,
> > @@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
> >  		}
> >  	};
> >  
> > +	if (len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c rd reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> >  	ret = i2c_transfer(priv->i2c, msg, 2);
> >  	if (ret == 2) {
> >  		memcpy(val, buf, len);
> > diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
> > index 81f38aae9c66..e27bf5be311d 100644
> > --- a/drivers/media/tuners/fc2580.c
> > +++ b/drivers/media/tuners/fc2580.c
> > @@ -41,7 +41,7 @@
> >  static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> >  {
> >  	int ret;
> > -	u8 buf[1 + len];
> > +	u8 buf[80];
> >  	struct i2c_msg msg[1] = {
> >  		{
> >  			.addr = priv->cfg->i2c_addr,
> > @@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> >  		}
> >  	};
> >  
> > +	if (1 + len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> >  	buf[0] = reg;
> >  	memcpy(&buf[1], val, len);
> >  
> > @@ -69,7 +76,7 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> >  static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> >  {
> >  	int ret;
> > -	u8 buf[len];
> > +	u8 buf[80];
> >  	struct i2c_msg msg[2] = {
> >  		{
> >  			.addr = priv->cfg->i2c_addr,
> > @@ -84,6 +91,13 @@ static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
> >  		}
> >  	};
> >  
> > +	if (len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c rd reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> >  	ret = i2c_transfer(priv->i2c, msg, 2);
> >  	if (ret == 2) {
> >  		memcpy(val, buf, len);
> > diff --git a/drivers/media/tuners/tda18212.c b/drivers/media/tuners/tda18212.c
> > index e4a84ee231cf..765b9f9d4bc6 100644
> > --- a/drivers/media/tuners/tda18212.c
> > +++ b/drivers/media/tuners/tda18212.c
> > @@ -32,7 +32,7 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> >  	int len)
> >  {
> >  	int ret;
> > -	u8 buf[len+1];
> > +	u8 buf[80];
> >  	struct i2c_msg msg[1] = {
> >  		{
> >  			.addr = priv->cfg->i2c_address,
> > @@ -42,6 +42,13 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> >  		}
> >  	};
> >  
> > +	if (1 + len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> >  	buf[0] = reg;
> >  	memcpy(&buf[1], val, len);
> >  
> > @@ -61,7 +68,7 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> >  	int len)
> >  {
> >  	int ret;
> > -	u8 buf[len];
> > +	u8 buf[80];
> >  	struct i2c_msg msg[2] = {
> >  		{
> >  			.addr = priv->cfg->i2c_address,
> > @@ -76,6 +83,13 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
> >  		}
> >  	};
> >  
> > +	if (len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c rd reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> >  	ret = i2c_transfer(priv->i2c, msg, 2);
> >  	if (ret == 2) {
> >  		memcpy(val, buf, len);
> > diff --git a/drivers/media/tuners/tda18218.c b/drivers/media/tuners/tda18218.c
> > index 2d31aeb6b088..e4e662c2e6ef 100644
> > --- a/drivers/media/tuners/tda18218.c
> > +++ b/drivers/media/tuners/tda18218.c
> > @@ -24,7 +24,7 @@
> >  static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> >  {
> >  	int ret = 0, len2, remaining;
> > -	u8 buf[1 + len];
> > +	u8 buf[80];
> >  	struct i2c_msg msg[1] = {
> >  		{
> >  			.addr = priv->cfg->i2c_address,
> > @@ -33,6 +33,13 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> >  		}
> >  	};
> >  
> > +	if (1 + len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> >  	for (remaining = len; remaining > 0;
> >  			remaining -= (priv->cfg->i2c_wr_max - 1)) {
> >  		len2 = remaining;
> > @@ -63,7 +70,7 @@ static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> >  static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> >  {
> >  	int ret;
> > -	u8 buf[reg+len]; /* we must start read always from reg 0x00 */
> > +	u8 buf[80]; /* we must start read always from reg 0x00 */
> >  	struct i2c_msg msg[2] = {
> >  		{
> >  			.addr = priv->cfg->i2c_address,
> > @@ -78,6 +85,13 @@ static int tda18218_rd_regs(struct tda18218_priv *priv, u8 reg, u8 *val, u8 len)
> >  		}
> >  	};
> >  
> > +	if (reg + len > sizeof(buf)) {
> > +		dev_warn(&priv->i2c->dev,
> > +			 "%s: i2c wr reg=%04x: len=%d is too big!\n",
> > +			 KBUILD_MODNAME, reg, len);
> > +		return -EREMOTEIO;
> > +	}
> > +
> >  	ret = i2c_transfer(priv->i2c, msg, 2);
> >  	if (ret == 2) {
> >  		memcpy(val, &buf[reg], len);
> > 
> 


-- 

Cheers,
Mauro

  reply	other threads:[~2013-11-02 21:15 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-02 13:31 [PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 01/29] tda9887: remove an warning when compiling for alpha Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 02/29] radio-shark: remove a warning when CONFIG_PM is not defined Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 03/29] zoran: don't build it on alpha Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 04/29] cx18: struct i2c_client is too big for stack Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 05/29] tef6862: fix warning on avr32 arch Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 06/29] iguanair: shut up a gcc " Mauro Carvalho Chehab
2013-11-03 22:10   ` Sean Young
2013-11-03 22:13     ` [PATCH] [media] iguanair: simplify calculation of carrier delay cycles Sean Young
2013-11-02 13:31 ` [PATCHv2 07/29] platform drivers: Fix build on cris and frv archs Mauro Carvalho Chehab
2013-11-04  4:03   ` Ben Hutchings
2013-11-04 11:28     ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 08/29] cx18: disable compilation on frv arch Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 09/29] radio-si470x-i2c: fix a warning on ia64 Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 10/29] rc: Fir warnings on m68k arch Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch Mauro Carvalho Chehab
2013-11-04 14:22   ` Laurent Pinchart
2013-11-04 14:43     ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 12/29] s5h1420: Don't use dynamic static allocation Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 13/29] dvb-frontends: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 14/29] " Mauro Carvalho Chehab
2013-11-02 17:10   ` Antti Palosaari
2013-11-02 13:31 ` [PATCHv2 15/29] stb0899_drv: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 16/29] stv0367: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 17/29] stv090x: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 18/29] av7110_hw: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 19/29] tuners: " Mauro Carvalho Chehab
2013-11-02 17:12   ` Antti Palosaari
2013-11-02 17:25   ` Hans Verkuil
2013-11-02 21:15     ` Mauro Carvalho Chehab [this message]
2013-11-02 21:53       ` Hans Verkuil
2013-11-02 21:59         ` Hans Verkuil
2013-11-03  0:21           ` Mauro Carvalho Chehab
2013-11-03  9:12             ` Mauro Carvalho Chehab
2013-11-03 11:54               ` Antti Palosaari
2013-11-04 13:26               ` Hans Verkuil
2013-11-04 14:24                 ` Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 20/29] tuner-xc2028: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 21/29] cimax2: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 22/29] v4l2-async: " Mauro Carvalho Chehab
2013-11-04 13:15   ` Hans Verkuil
2013-11-05 11:36     ` Mauro Carvalho Chehab
2013-11-05 11:42       ` Sylwester Nawrocki
2013-11-05 12:03         ` Mauro Carvalho Chehab
2013-11-05 12:35           ` Hans Verkuil
2013-11-05 13:16             ` Mauro Carvalho Chehab
2013-11-05 14:18               ` Hans Verkuil
2013-11-02 13:31 ` [PATCHv2 23/29] cxusb: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 24/29] dibusb-common: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 25/29] dw2102: " Mauro Carvalho Chehab
2013-11-02 13:31 ` [PATCHv2 26/29] af9015: " Mauro Carvalho Chehab
2013-11-02 17:05   ` Antti Palosaari
2013-11-02 13:31 ` [PATCHv2 27/29] af9035: " Mauro Carvalho Chehab
2013-11-02 17:19   ` Antti Palosaari
2013-11-02 13:31 ` [PATCHv2 28/29] mxl111sf: " Mauro Carvalho Chehab
2013-11-04  0:50   ` Michael Krufky
2013-11-04 10:58     ` Mauro Carvalho Chehab
2013-11-04 11:04       ` Michael Krufky
2013-11-02 13:31 ` [PATCHv2 29/29] lirc_zilog: " 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=20131102191515.0af09112@samsung.com \
    --to=m.chehab@samsung.com \
    --cc=crope@iki.fi \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.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.