This is a note to let you know that I've just added the patch titled
media: dibusb-common: Don't use dynamic static allocation
to the 3.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
media-dibusb-common-don-t-use-dynamic-static-allocation.patch
and it can be found in the queue-3.12 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 1d7fa359d4c0fbb2756fa01cc47212908d90b7b0 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
Date: Sat, 2 Nov 2013 07:23:49 -0300
Subject: media: dibusb-common: Don't use dynamic static allocation
From: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
commit 1d7fa359d4c0fbb2756fa01cc47212908d90b7b0 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/dibusb-common.c:124:1: warning: 'dibusb_i2c_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (64 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
Reviewed-by: Hans Verkuil <hans.verkuil@xxxxxxxxx>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@xxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/media/usb/dvb-usb/dibusb-common.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/media/usb/dvb-usb/dibusb-common.c
+++ b/drivers/media/usb/dvb-usb/dibusb-common.c
@@ -12,6 +12,9 @@
#include <linux/kconfig.h>
#include "dibusb.h"
+/* Max transfer size done by I2C transfer functions */
+#define MAX_XFER_SIZE 64
+
static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "set debugging level (1=info (|-able))." DVB_USB_DEBUG_STATUS);
@@ -105,11 +108,16 @@ EXPORT_SYMBOL(dibusb2_0_power_ctrl);
static int dibusb_i2c_msg(struct dvb_usb_device *d, u8 addr,
u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen)
{
- u8 sndbuf[wlen+4]; /* lead(1) devaddr,direction(1) addr(2) data(wlen) (len(2) (when reading)) */
+ u8 sndbuf[MAX_XFER_SIZE]; /* lead(1) devaddr,direction(1) addr(2) data(wlen) (len(2) (when reading)) */
/* write only ? */
int wo = (rbuf == NULL || rlen == 0),
len = 2 + wlen + (wo ? 0 : 2);
+ if (4 + wlen > sizeof(sndbuf)) {
+ warn("i2c wr: len=%d is too big!\n", wlen);
+ return -EOPNOTSUPP;
+ }
+
sndbuf[0] = wo ? DIBUSB_REQ_I2C_WRITE : DIBUSB_REQ_I2C_READ;
sndbuf[1] = (addr << 1) | (wo ? 0 : 1);
Patches currently in stable-queue which might be from m.chehab@xxxxxxxxxxx are
queue-3.12/media-af9015-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-dw2102-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-af9035-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-stb0899_drv-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-dibusb-common-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-cx18-struct-i2c_client-is-too-big-for-stack.patch
queue-3.12/media-tuner-xc2028-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-cimax2-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-tuners-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-v4l2-async-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-dvb-frontends-again-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-dvb-frontends-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-stv090x-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-s5h1420-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-av7110_hw-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-stv0367-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-lirc_zilog-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-cxusb-don-t-use-dynamic-static-allocation.patch
queue-3.12/media-mxl111sf-don-t-use-dynamic-static-allocation.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html