This is the start of the stable review cycle for the 2.6.37.r release.
There are 29 patches in this series, all will be posted as a response to
this one. If anyone has any issues with these being applied, please let
us know. If anyone is a maintainer of the proper subsystem, and wants
to add a Signed-off-by: line to the patch, please respond with it.
Responses should be made by Saturday, March 12, 24:00:00 UTC.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.37.4-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
Makefile | 2 +-
arch/x86/kernel/cpu/cpufreq/pcc-cpufreq.c | 2 +-
drivers/char/virtio_console.c | 8 ++++
drivers/hid/hid-mosart.c | 4 ++
drivers/media/dvb/dvb-usb/dib0700_devices.c | 21 +++++++++-
drivers/media/dvb/frontends/dib7000m.c | 19 +++++++++
drivers/media/dvb/frontends/dib7000m.h | 15 +++++++
drivers/media/video/cx23885/cx23885-i2c.c | 8 ----
drivers/media/video/cx25840/cx25840-core.c | 3 +-
drivers/media/video/ivtv/ivtv-irq.c | 58 +++++++++++++++++++++++---
drivers/misc/bmp085.c | 1 +
drivers/net/forcedeth.c | 2 +
drivers/net/ixgbe/ixgbe_main.c | 4 ++
drivers/net/r8169.c | 42 +++++++++++++++----
drivers/net/wireless/ath/ath9k/ath9k.h | 3 -
drivers/net/wireless/ath/ath9k/init.c | 4 --
drivers/net/wireless/ath/ath9k/main.c | 4 --
drivers/s390/char/keyboard.c | 3 +-
fs/nfs/nfs4proc.c | 44 +++++++++++++++++++-
fs/nfs/nfs4xdr.c | 3 -
fs/nfsd/nfs4xdr.c | 4 +-
include/keys/rxrpc-type.h | 1 -
include/linux/netdevice.h | 3 +
kernel/cpuset.c | 7 ++-
kernel/sched_rt.c | 14 ++++--
mm/mremap.c | 4 +-
net/core/dev.c | 12 +++++-
net/ipv4/ip_gre.c | 1 +
net/ipv4/ipip.c | 1 +
net/ipv4/netfilter/arpt_mangle.c | 6 +-
net/ipv6/sit.c | 2 +-
net/netfilter/ipvs/ip_vs_ctl.c | 4 +-
net/netfilter/nf_log.c | 4 ++
sound/pci/hda/patch_cirrus.c | 2 +
sound/pci/hda/patch_realtek.c | 7 +--
sound/soc/codecs/wm9081.c | 5 ++
36 files changed, 255 insertions(+), 72 deletions(-)
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Li Zefan <[email protected]>
commit b75f38d659e6fc747eda64cb72f3920e29dd44a4 upstream.
Don't forget to release cgroup_mutex if alloc_trial_cpuset() fails.
[[email protected]: avoid multiple return points]
Signed-off-by: Li Zefan <[email protected]>
Cc: Paul Menage <[email protected]>
Acked-by: David Rientjes <[email protected]>
Cc: Miao Xie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/cpuset.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -1575,8 +1575,10 @@ static int cpuset_write_resmask(struct c
return -ENODEV;
trialcs = alloc_trial_cpuset(cs);
- if (!trialcs)
- return -ENOMEM;
+ if (!trialcs) {
+ retval = -ENOMEM;
+ goto out;
+ }
switch (cft->private) {
case FILE_CPULIST:
@@ -1591,6 +1593,7 @@ static int cpuset_write_resmask(struct c
}
free_trial_cpuset(trialcs);
+out:
cgroup_unlock();
return retval;
}
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Dan Carpenter <[email protected]>
commit b652277b09d3d030cb074cc6a98ba80b34244c03 upstream.
The "ct" variable should be an unsigned int. Both struct kbdiacrs
->kb_cnt and struct kbd_data ->accent_table_size are unsigned ints.
Making it signed causes a problem in KBDIACRUC because the user could
set the signed bit and cause a buffer overflow.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/s390/char/keyboard.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/s390/char/keyboard.c
+++ b/drivers/s390/char/keyboard.c
@@ -460,7 +460,8 @@ kbd_ioctl(struct kbd_data *kbd, struct f
unsigned int cmd, unsigned long arg)
{
void __user *argp;
- int ct, perm;
+ unsigned int ct;
+ int perm;
argp = (void __user *)arg;
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Neil Horman <[email protected]>
commit e9e3d724e2145f5039b423c290ce2b2c3d8f94bc upstream.
The "bad_page()" page allocator sanity check was reported recently (call
chain as follows):
bad_page+0x69/0x91
free_hot_cold_page+0x81/0x144
skb_release_data+0x5f/0x98
__kfree_skb+0x11/0x1a
tcp_ack+0x6a3/0x1868
tcp_rcv_established+0x7a6/0x8b9
tcp_v4_do_rcv+0x2a/0x2fa
tcp_v4_rcv+0x9a2/0x9f6
do_timer+0x2df/0x52c
ip_local_deliver+0x19d/0x263
ip_rcv+0x539/0x57c
netif_receive_skb+0x470/0x49f
:virtio_net:virtnet_poll+0x46b/0x5c5
net_rx_action+0xac/0x1b3
__do_softirq+0x89/0x133
call_softirq+0x1c/0x28
do_softirq+0x2c/0x7d
do_IRQ+0xec/0xf5
default_idle+0x0/0x50
ret_from_intr+0x0/0xa
default_idle+0x29/0x50
cpu_idle+0x95/0xb8
start_kernel+0x220/0x225
_sinittext+0x22f/0x236
It occurs because an skb with a fraglist was freed from the tcp
retransmit queue when it was acked, but a page on that fraglist had
PG_Slab set (indicating it was allocated from the Slab allocator (which
means the free path above can't safely free it via put_page.
We tracked this back to an nfsv4 setacl operation, in which the nfs code
attempted to fill convert the passed in buffer to an array of pages in
__nfs4_proc_set_acl, which gets used by the skb->frags list in
xs_sendpages. __nfs4_proc_set_acl just converts each page in the buffer
to a page struct via virt_to_page, but the vfs allocates the buffer via
kmalloc, meaning the PG_slab bit is set. We can't create a buffer with
kmalloc and free it later in the tcp ack path with put_page, so we need
to either:
1) ensure that when we create the list of pages, no page struct has
PG_Slab set
or
2) not use a page list to send this data
Given that these buffers can be multiple pages and arbitrarily sized, I
think (1) is the right way to go. I've written the below patch to
allocate a page from the buddy allocator directly and copy the data over
to it. This ensures that we have a put_page free-able page for every
entry that winds up on an skb frag list, so it can be safely freed when
the frame is acked. We do a put page on each entry after the
rpc_call_sync call so as to drop our own reference count to the page,
leaving only the ref count taken by tcp_sendpages. This way the data
will be properly freed when the ack comes in
Successfully tested by myself to solve the above oops.
Note, as this is the result of a setacl operation that exceeded a page
of data, I think this amounts to a local DOS triggerable by an
uprivlidged user, so I'm CCing security on this as well.
Signed-off-by: Neil Horman <[email protected]>
CC: Trond Myklebust <[email protected]>
CC: Jeff Layton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/nfs4proc.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 42 insertions(+), 2 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -49,6 +49,7 @@
#include <linux/mount.h>
#include <linux/module.h>
#include <linux/sunrpc/bc_xprt.h>
+#include <linux/mm.h>
#include "nfs4_fs.h"
#include "delegation.h"
@@ -3216,6 +3217,35 @@ static void buf_to_pages(const void *buf
}
}
+static int buf_to_pages_noslab(const void *buf, size_t buflen,
+ struct page **pages, unsigned int *pgbase)
+{
+ struct page *newpage, **spages;
+ int rc = 0;
+ size_t len;
+ spages = pages;
+
+ do {
+ len = min(PAGE_CACHE_SIZE, buflen);
+ newpage = alloc_page(GFP_KERNEL);
+
+ if (newpage == NULL)
+ goto unwind;
+ memcpy(page_address(newpage), buf, len);
+ buf += len;
+ buflen -= len;
+ *pages++ = newpage;
+ rc++;
+ } while (buflen != 0);
+
+ return rc;
+
+unwind:
+ for(; rc > 0; rc--)
+ __free_page(spages[rc-1]);
+ return -ENOMEM;
+}
+
struct nfs4_cached_acl {
int cached;
size_t len;
@@ -3384,13 +3414,23 @@ static int __nfs4_proc_set_acl(struct in
.rpc_argp = &arg,
.rpc_resp = &res,
};
- int ret;
+ int ret, i;
if (!nfs4_server_supports_acls(server))
return -EOPNOTSUPP;
+ i = buf_to_pages_noslab(buf, buflen, arg.acl_pages, &arg.acl_pgbase);
+ if (i < 0)
+ return i;
nfs_inode_return_delegation(inode);
- buf_to_pages(buf, buflen, arg.acl_pages, &arg.acl_pgbase);
ret = nfs4_call_sync(server, &msg, &arg, &res, 1);
+
+ /*
+ * Free each page after tx, so the only ref left is
+ * held by the network stack
+ */
+ for (; i > 0; i--)
+ put_page(pages[i-1]);
+
/*
* Acl update can result in inode attribute update.
* so mark the attribute cache invalid.
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: roel <[email protected]>
commit 3ec07aa9522e3d5e9d5ede7bef946756e623a0a0 upstream.
Index i was already used in the outer loop
Signed-off-by: Roel Kluin <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfsd/nfs4xdr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1107,7 +1107,7 @@ nfsd4_decode_create_session(struct nfsd4
u32 dummy;
char *machine_name;
- int i;
+ int i, j;
int nr_secflavs;
READ_BUF(16);
@@ -1180,7 +1180,7 @@ nfsd4_decode_create_session(struct nfsd4
READ_BUF(4);
READ32(dummy);
READ_BUF(dummy * 4);
- for (i = 0; i < dummy; ++i)
+ for (j = 0; j < dummy; ++j)
READ32(dummy);
break;
case RPC_AUTH_GSS:
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Francois Romieu <[email protected]>
commit 1519e57fe81c14bb8fa4855579f19264d1ef63b4 upstream.
Some experiment-based action to prevent my 8168 chipsets locking-up hard
in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not
always mandatory (is it at all ?).
- RTL_GIGA_MAC_VER_12
- RTL_GIGA_MAC_VER_25
Missed ~55% packets. Note:
- this is an old SiS 965L motherboard
- the 8168 chipset emits (lots of) control frames towards the sender
- RTL_GIGA_MAC_VER_26
The chipset does not go into a frenzy of mac control pause when it
crashes yet but it can still be crashed. It needs more work.
Signed-off-by: Francois Romieu <[email protected]>
Cc: Ivan Vecera <[email protected]>
Cc: Hayes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/r8169.c | 30 +++++++++++++++++++++---------
1 file changed, 21 insertions(+), 9 deletions(-)
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -758,7 +758,8 @@ static void __rtl8169_check_link_status(
if (pm)
pm_request_resume(&tp->pci_dev->dev);
netif_carrier_on(dev);
- netif_info(tp, ifup, dev, "link up\n");
+ if (net_ratelimit())
+ netif_info(tp, ifup, dev, "link up\n");
} else {
netif_carrier_off(dev);
netif_info(tp, ifdown, dev, "link down\n");
@@ -4603,13 +4604,24 @@ static irqreturn_t rtl8169_interrupt(int
break;
}
- /* Work around for rx fifo overflow */
- if (unlikely(status & RxFIFOOver) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
- tp->mac_version == RTL_GIGA_MAC_VER_22)) {
- netif_stop_queue(dev);
- rtl8169_tx_timeout(dev);
- break;
+ if (unlikely(status & RxFIFOOver)) {
+ switch (tp->mac_version) {
+ /* Work around for rx fifo overflow */
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_22:
+ case RTL_GIGA_MAC_VER_26:
+ netif_stop_queue(dev);
+ rtl8169_tx_timeout(dev);
+ goto done;
+ /* Experimental science. Pktgen proof. */
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_25:
+ if (status == RxFIFOOver)
+ goto done;
+ break;
+ default:
+ break;
+ }
}
if (unlikely(status & SYSErr)) {
@@ -4645,7 +4657,7 @@ static irqreturn_t rtl8169_interrupt(int
(status & RxFIFOOver) ? (status | RxOverflow) : status);
status = RTL_R16(IntrStatus);
}
-
+done:
return IRQ_RETVAL(handled);
}
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Olivier Grenie <[email protected]>
commit e192a7cf0effe7680264a5bc35c0ad1bdcdc921c upstream.
This patch adds the pid filtering for the dib7000M demod. It also
corrects the pid filtering for the dib7700 based board. It should
prevent an oops, when using dib7700p based board.
References: https://bugzilla.novell.com/show_bug.cgi?id=644807
Signed-off-by: Olivier Grenie <[email protected]>
Signed-off-by: Patrick Boettcher <[email protected]>
Tested-by: Pavel SKARKA <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb/dvb-usb/dib0700_devices.c | 21 +++++++++++++++++++--
drivers/media/dvb/frontends/dib7000m.c | 19 +++++++++++++++++++
drivers/media/dvb/frontends/dib7000m.h | 15 +++++++++++++++
3 files changed, 53 insertions(+), 2 deletions(-)
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -870,6 +870,23 @@ static int dib7070p_tuner_attach(struct
return 0;
}
+static int stk7700p_pid_filter(struct dvb_usb_adapter *adapter, int index,
+ u16 pid, int onoff)
+{
+ struct dib0700_state *st = adapter->dev->priv;
+ if (st->is_dib7000pc)
+ return dib7000p_pid_filter(adapter->fe, index, pid, onoff);
+ return dib7000m_pid_filter(adapter->fe, index, pid, onoff);
+}
+
+static int stk7700p_pid_filter_ctrl(struct dvb_usb_adapter *adapter, int onoff)
+{
+ struct dib0700_state *st = adapter->dev->priv;
+ if (st->is_dib7000pc)
+ return dib7000p_pid_filter_ctrl(adapter->fe, onoff);
+ return dib7000m_pid_filter_ctrl(adapter->fe, onoff);
+}
+
static int stk70x0p_pid_filter(struct dvb_usb_adapter *adapter, int index, u16 pid, int onoff)
{
return dib7000p_pid_filter(adapter->fe, index, pid, onoff);
@@ -1875,8 +1892,8 @@ struct dvb_usb_device_properties dib0700
{
.caps = DVB_USB_ADAP_HAS_PID_FILTER | DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
.pid_filter_count = 32,
- .pid_filter = stk70x0p_pid_filter,
- .pid_filter_ctrl = stk70x0p_pid_filter_ctrl,
+ .pid_filter = stk7700p_pid_filter,
+ .pid_filter_ctrl = stk7700p_pid_filter_ctrl,
.frontend_attach = stk7700p_frontend_attach,
.tuner_attach = stk7700p_tuner_attach,
--- a/drivers/media/dvb/frontends/dib7000m.c
+++ b/drivers/media/dvb/frontends/dib7000m.c
@@ -1285,6 +1285,25 @@ struct i2c_adapter * dib7000m_get_i2c_ma
}
EXPORT_SYMBOL(dib7000m_get_i2c_master);
+int dib7000m_pid_filter_ctrl(struct dvb_frontend *fe, u8 onoff)
+{
+ struct dib7000m_state *state = fe->demodulator_priv;
+ u16 val = dib7000m_read_word(state, 294 + state->reg_offs) & 0xffef;
+ val |= (onoff & 0x1) << 4;
+ dprintk("PID filter enabled %d", onoff);
+ return dib7000m_write_word(state, 294 + state->reg_offs, val);
+}
+EXPORT_SYMBOL(dib7000m_pid_filter_ctrl);
+
+int dib7000m_pid_filter(struct dvb_frontend *fe, u8 id, u16 pid, u8 onoff)
+{
+ struct dib7000m_state *state = fe->demodulator_priv;
+ dprintk("PID filter: index %x, PID %d, OnOff %d", id, pid, onoff);
+ return dib7000m_write_word(state, 300 + state->reg_offs + id,
+ onoff ? (1 << 13) | pid : 0);
+}
+EXPORT_SYMBOL(dib7000m_pid_filter);
+
#if 0
/* used with some prototype boards */
int dib7000m_i2c_enumeration(struct i2c_adapter *i2c, int no_of_demods,
--- a/drivers/media/dvb/frontends/dib7000m.h
+++ b/drivers/media/dvb/frontends/dib7000m.h
@@ -46,6 +46,8 @@ extern struct dvb_frontend *dib7000m_att
extern struct i2c_adapter *dib7000m_get_i2c_master(struct dvb_frontend *,
enum dibx000_i2c_interface,
int);
+extern int dib7000m_pid_filter(struct dvb_frontend *, u8 id, u16 pid, u8 onoff);
+extern int dib7000m_pid_filter_ctrl(struct dvb_frontend *fe, u8 onoff);
#else
static inline
struct dvb_frontend *dib7000m_attach(struct i2c_adapter *i2c_adap,
@@ -63,6 +65,19 @@ struct i2c_adapter *dib7000m_get_i2c_mas
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
return NULL;
}
+static inline int dib7000m_pid_filter(struct dvb_frontend *fe, u8 id,
+ u16 pid, u8 onoff)
+{
+ printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
+ return -ENODEV;
+}
+
+static inline int dib7000m_pid_filter_ctrl(struct dvb_frontend *fe,
+ uint8_t onoff)
+{
+ printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
+ return -ENODEV;
+}
#endif
/* TODO
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ivan Vecera <[email protected]>
commit b5ba6d12bdac21bc0620a5089e0f24e362645efd upstream.
I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts
generating RxFIFO overflow errors. The result is an infinite loop in
interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11.
With the workaround everything goes fine.
Signed-off-by: Ivan Vecera <[email protected]>
Acked-by: Francois Romieu <[email protected]>
Cc: Hayes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/r8169.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3725,7 +3725,8 @@ static void rtl_hw_start_8168(struct net
RTL_W16(IntrMitigate, 0x5151);
/* Work around for RxFIFO overflow. */
- if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_22) {
tp->intr_event |= RxFIFOOver | PCSTimeout;
tp->intr_event &= ~RxOverflow;
}
@@ -4604,7 +4605,8 @@ static irqreturn_t rtl8169_interrupt(int
/* Work around for rx fifo overflow */
if (unlikely(status & RxFIFOOver) &&
- (tp->mac_version == RTL_GIGA_MAC_VER_11)) {
+ (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_22)) {
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
break;
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Sven Barth <[email protected]>
commit 1e6406b8f0dc1ae7d7c39c9e1ac6ca78e016ebfb upstream.
Fix the probing of cx2583x chips, because two controls were clustered
that are not created for these chips.
This regression was introduced in 2.6.36.
Signed-off-by: Sven Barth <[email protected]>
Signed-off-by: Andy Walls <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/video/cx25840/cx25840-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -2031,7 +2031,8 @@ static int cx25840_probe(struct i2c_clie
kfree(state);
return err;
}
- v4l2_ctrl_cluster(2, &state->volume);
+ if (!is_cx2583x(state))
+ v4l2_ctrl_cluster(2, &state->volume);
v4l2_ctrl_handler_setup(&state->hdl);
cx25840_ir_probe(sd);
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Andy Walls <[email protected]>
commit 67914b5c400d6c213f9e56d7547a2038ab5c06f4 upstream.
This reverts commit 44835f197bf1e3f57464f23dfb239fef06cf89be.
With the CX23885 hardware I2C master, checking for I2C slave ACK/NAK
is not valid when the I2C_EXTEND or I2C_NOSTOP bits are set.
Revert the commit that checks for I2C slave ACK/NAK on all transactions,
so that XC5000 tuners work with the CX23885 again.
Thanks go to Mark Zimmerman for reporting and bisecting this problem.
Bisected-by: Mark Zimmerman <[email protected]>
Reported-by: Mark Zimmerman <[email protected]>
Signed-off-by: Andy Walls <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/video/cx23885/cx23885-i2c.c | 8 --------
1 file changed, 8 deletions(-)
--- a/drivers/media/video/cx23885/cx23885-i2c.c
+++ b/drivers/media/video/cx23885/cx23885-i2c.c
@@ -122,10 +122,6 @@ static int i2c_sendbytes(struct i2c_adap
if (!i2c_wait_done(i2c_adap))
goto eio;
- if (!i2c_slave_did_ack(i2c_adap)) {
- retval = -ENXIO;
- goto err;
- }
if (i2c_debug) {
printk(" <W %02x %02x", msg->addr << 1, msg->buf[0]);
if (!(ctrl & I2C_NOSTOP))
@@ -209,10 +205,6 @@ static int i2c_readbytes(struct i2c_adap
if (!i2c_wait_done(i2c_adap))
goto eio;
- if (cnt == 0 && !i2c_slave_did_ack(i2c_adap)) {
- retval = -ENXIO;
- goto err;
- }
msg->buf[cnt] = cx_read(bus->reg_rdata) & 0xff;
if (i2c_debug) {
dprintk(1, " %02x", msg->buf[cnt]);
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael <[email protected]>
commit d213ad08362909ab50fbd6568fcc9fd568268d29 upstream.
After upgrading the kernel from stock Ubuntu 7.10 to
10.04, with no hardware changes, I started getting the dreaded DMA
TIMEOUT errors, followed by inability to encode until the machine was
rebooted.
I came across a post from Andy in March
(http://www.gossamer-threads.com/lists/ivtv/users/40943#40943) where he
speculates that perhaps the corrective actions being taken after a DMA
ERROR are not sufficient to recover the situation. After some testing
I suspect that this is indeed the case, and that in fact the corrective
action may be what hangs the card's DMA engine, rather than the
original error.
Specifically these DMA ERROR IRQs seem to present with two different
values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13. The current
corrective action is to clear that status register back to 0x01 or
0x03, and then issue the next DMA request. In the case of a 0x13 this
seems to result in a minor glitch in the encoded stream due to the
failed transfer that was not retried, but otherwise things continue OK.
In the case of a 0x11 the card's DMA write engine is never heard from
again, and a DMA TIMEOUT follows shortly after. 0x11 is the killer.
I suspect that the two cases need to be handled differently. The
difference is in bit 1 (0x02), which is set when the error is about to
be successfully recovered, and clear when things are about to go bad.
Bit 1 of DMASTATUS is described differently in different places either
as a positive "write finished", or an inverted "write busy". If we
take the first definition, then when an error arises with state 0x11,
it means that the write did not complete. It makes sense to start a
new transfer, as in the current code. But if we take the second
definition, then 0x11 means "an error but the write engine is still
busy". Trying to feed it a new transfer in this situation might not be
a good idea.
As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS
is 0x11. I.e., don't start a new transfer, don't clear our flags, etc.
The hope was that the card would complete the transfer and issue a ENC
DMA COMPLETE, either successfully or with an error condition there.
However the card still hung.
The only remaining corrective action being taken with a 0x11 status was
then the write back to the status register to clear the error, i.e.
DMASTATUS = DMASTATUS & ~3. This would have the effect of clearing the
error bit 4, while leaving the lower bits indicating DMA write busy.
Strangely enough, removing this write to the status register solved the
problem! If the DMA ERROR IRQ with DMASTATUS=0x11 is completely
ignored, with no corrective action at all, then the card will complete
the transfer and issue a new IRQ. If the status register is written to
when it has the value 0x11, then the DMA engine hangs. Perhaps it's
illegal to write to
DMASTATUS while the read or write busy bit is set? At any rate, it
appears that the current corrective action is indeed making things
worse rather than better.
I put together a patch that modifies ivtv_irq_dma_err to do the
following:
- Don't write back to IVTV_REG_DMASTATUS.
- If write-busy is asserted, leave the card alone. Just extend the
timeout slightly.
- If write-busy is de-asserted, retry the current transfer.
This has completely fixed my DMA TIMEOUT woes. DMA ERR events still
occur, but now they seem to be correctly handled. 0x11 events no
longer hang the card, and 0x13 events no longer result in a glitch in
the stream, as the failed transfer is retried. I'm happy.
I've inlined the patch below in case it is of interest. As described
above, I have a theory about why it works (based on a different
interpretation of bit 1 of DMASTATUS), but I can't guarantee that my
theory is correct. There may be another explanation, or it may be a
fluke. Maybe ignoring that IRQ entirely would be equally effective?
Maybe the status register read/writeback sequence is race condition if
the card changes it in the mean time? Also as I am using a PVR-150
only, I have not been able to test it on other cards, which may be
especially relevant for 350s that support concurrent decoding.
Hopefully the patch does not break the DMA READ path.
Mike
[[email protected]: Modified patch to add a verbose comment, make minor
brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both
read and write DMA were not in progress. Mike's conjecture about a race
condition with the writeback is correct; it can confuse the DMA engine.]
[Comment and analysis from the ML post by Michael <[email protected]>]
Signed-off-by: Andy Walls <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/video/ivtv/ivtv-irq.c | 58 +++++++++++++++++++++++++++++++-----
1 file changed, 51 insertions(+), 7 deletions(-)
--- a/drivers/media/video/ivtv/ivtv-irq.c
+++ b/drivers/media/video/ivtv/ivtv-irq.c
@@ -628,22 +628,66 @@ static void ivtv_irq_enc_pio_complete(st
static void ivtv_irq_dma_err(struct ivtv *itv)
{
u32 data[CX2341X_MBOX_MAX_DATA];
+ u32 status;
del_timer(&itv->dma_timer);
+
ivtv_api_get_data(&itv->enc_mbox, IVTV_MBOX_DMA_END, 2, data);
+ status = read_reg(IVTV_REG_DMASTATUS);
IVTV_DEBUG_WARN("DMA ERROR %08x %08x %08x %d\n", data[0], data[1],
- read_reg(IVTV_REG_DMASTATUS), itv->cur_dma_stream);
- write_reg(read_reg(IVTV_REG_DMASTATUS) & 3, IVTV_REG_DMASTATUS);
+ status, itv->cur_dma_stream);
+ /*
+ * We do *not* write back to the IVTV_REG_DMASTATUS register to
+ * clear the error status, if either the encoder write (0x02) or
+ * decoder read (0x01) bus master DMA operation do not indicate
+ * completed. We can race with the DMA engine, which may have
+ * transitioned to completed status *after* we read the register.
+ * Setting a IVTV_REG_DMASTATUS flag back to "busy" status, after the
+ * DMA engine has completed, will cause the DMA engine to stop working.
+ */
+ status &= 0x3;
+ if (status == 0x3)
+ write_reg(status, IVTV_REG_DMASTATUS);
+
if (!test_bit(IVTV_F_I_UDMA, &itv->i_flags) &&
itv->cur_dma_stream >= 0 && itv->cur_dma_stream < IVTV_MAX_STREAMS) {
struct ivtv_stream *s = &itv->streams[itv->cur_dma_stream];
- /* retry */
- if (s->type >= IVTV_DEC_STREAM_TYPE_MPG)
+ if (s->type >= IVTV_DEC_STREAM_TYPE_MPG) {
+ /* retry */
+ /*
+ * FIXME - handle cases of DMA error similar to
+ * encoder below, except conditioned on status & 0x1
+ */
ivtv_dma_dec_start(s);
- else
- ivtv_dma_enc_start(s);
- return;
+ return;
+ } else {
+ if ((status & 0x2) == 0) {
+ /*
+ * CX2341x Bus Master DMA write is ongoing.
+ * Reset the timer and let it complete.
+ */
+ itv->dma_timer.expires =
+ jiffies + msecs_to_jiffies(600);
+ add_timer(&itv->dma_timer);
+ return;
+ }
+
+ if (itv->dma_retries < 3) {
+ /*
+ * CX2341x Bus Master DMA write has ended.
+ * Retry the write, starting with the first
+ * xfer segment. Just retrying the current
+ * segment is not sufficient.
+ */
+ s->sg_processed = 0;
+ itv->dma_retries++;
+ ivtv_dma_enc_start_xfer(s);
+ return;
+ }
+ /* Too many retries, give up on this one */
+ }
+
}
if (test_bit(IVTV_F_I_UDMA, &itv->i_flags)) {
ivtv_udma_start(itv);
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Balbir Singh <[email protected]>
commit 0c3b9168017cbad2c4af3dd65ec93fe646eeaa62 upstream.
The current sched rt code is broken when it comes to hierarchical
scheduling, this patch fixes two problems
1. It adds redundant enqueuing (harmless) when it finds a queue
has tasks enqueued, but it has no run time and it is not
throttled.
2. The most important change is in sched_rt_rq_enqueue/dequeue.
The code just picks the rt_rq belonging to the current cpu
on which the period timer runs, the patch fixes it, so that
the correct rt_se is enqueued/dequeued.
Tested with a simple hierarchy
/c/d, c and d assigned similar runtimes of 50,000 and a while
1 loop runs within "d". Both c and d get throttled, without
the patch, the task just stops running and never runs (depends
on where the sched_rt b/w timer runs). With the patch, the
task is throttled and runs as expected.
[ bharata, suggestions on how to pick the rt_se belong to the
rt_rq and correct cpu ]
Signed-off-by: Balbir Singh <[email protected]>
Acked-by: Bharata B Rao <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/sched_rt.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -199,11 +199,12 @@ static void dequeue_rt_entity(struct sch
static void sched_rt_rq_enqueue(struct rt_rq *rt_rq)
{
- int this_cpu = smp_processor_id();
struct task_struct *curr = rq_of_rt_rq(rt_rq)->curr;
struct sched_rt_entity *rt_se;
- rt_se = rt_rq->tg->rt_se[this_cpu];
+ int cpu = cpu_of(rq_of_rt_rq(rt_rq));
+
+ rt_se = rt_rq->tg->rt_se[cpu];
if (rt_rq->rt_nr_running) {
if (rt_se && !on_rt_rq(rt_se))
@@ -215,10 +216,10 @@ static void sched_rt_rq_enqueue(struct r
static void sched_rt_rq_dequeue(struct rt_rq *rt_rq)
{
- int this_cpu = smp_processor_id();
struct sched_rt_entity *rt_se;
+ int cpu = cpu_of(rq_of_rt_rq(rt_rq));
- rt_se = rt_rq->tg->rt_se[this_cpu];
+ rt_se = rt_rq->tg->rt_se[cpu];
if (rt_se && on_rt_rq(rt_se))
dequeue_rt_entity(rt_se);
@@ -546,8 +547,11 @@ static int do_sched_rt_period_timer(stru
if (rt_rq->rt_time || rt_rq->rt_nr_running)
idle = 0;
raw_spin_unlock(&rt_rq->rt_runtime_lock);
- } else if (rt_rq->rt_nr_running)
+ } else if (rt_rq->rt_nr_running) {
idle = 0;
+ if (!rt_rq_throttled(rt_rq))
+ enqueue = 1;
+ }
if (enqueue)
sched_rt_rq_enqueue(rt_rq);
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Ivan Vecera <[email protected]>
commit 0d672e9f8ac320c6d1ea9103db6df7f99ea20361 upstream.
Without calling of netif_carrier_off at the end of the probe the operstate
is unknown when the device is initially opened. By default the carrier is
on so when the device is opened and netif_carrier_on is called the link
watch event is not fired and operstate remains zero (unknown).
This patch fixes this behavior in forcedeth and r8169.
Signed-off-by: Ivan Vecera <[email protected]>
Acked-by: Francois Romieu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/forcedeth.c | 2 ++
drivers/net/r8169.c | 2 ++
2 files changed, 4 insertions(+)
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5816,6 +5816,8 @@ static int __devinit nv_probe(struct pci
goto out_error;
}
+ netif_carrier_off(dev);
+
dev_printk(KERN_INFO, &pci_dev->dev, "ifname %s, PHY OUI 0x%x @ %d, "
"addr %2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x\n",
dev->name,
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3236,6 +3236,8 @@ rtl8169_init_one(struct pci_dev *pdev, c
if (pci_dev_run_wake(pdev))
pm_runtime_put_noidle(&pdev->dev);
+ netif_carrier_off(dev);
+
out:
return rc;
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Pablo Neira Ayuso <[email protected]>
commit 9d0db8b6b1da9e3d4c696ef29449700c58d589db upstream.
In 135367b "netfilter: xtables: change xt_target.checkentry return type",
the type returned by checkentry was changed from boolean to int, but the
return values where not adjusted.
arptables: Input/output error
This broke arptables with the mangle target since it returns true
under success, which is interpreted by xtables as >0, thus
returning EIO.
Signed-off-by: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/netfilter/arpt_mangle.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/arpt_mangle.c
+++ b/net/ipv4/netfilter/arpt_mangle.c
@@ -60,12 +60,12 @@ static int checkentry(const struct xt_tg
if (mangle->flags & ~ARPT_MANGLE_MASK ||
!(mangle->flags & ARPT_MANGLE_MASK))
- return false;
+ return -EINVAL;
if (mangle->target != NF_DROP && mangle->target != NF_ACCEPT &&
mangle->target != XT_CONTINUE)
- return false;
- return true;
+ return -EINVAL;
+ return 0;
}
static struct xt_target arpt_mangle_reg __read_mostly = {
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Francois Romieu <[email protected]>
commit f60ac8e7ab7cbb413a0131d5665b053f9f386526 upstream.
While the RxFIFO interruption is masked for most 8168, nothing prevents
it to appear in the irq status word. This is no excuse to crash.
Signed-off-by: Francois Romieu <[email protected]>
Cc: Ivan Vecera <[email protected]>
Cc: Hayes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/r8169.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -4613,6 +4613,14 @@ static irqreturn_t rtl8169_interrupt(int
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
goto done;
+ /* Testers needed. */
+ case RTL_GIGA_MAC_VER_17:
+ case RTL_GIGA_MAC_VER_19:
+ case RTL_GIGA_MAC_VER_20:
+ case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_23:
+ case RTL_GIGA_MAC_VER_24:
+ case RTL_GIGA_MAC_VER_27:
/* Experimental science. Pktgen proof. */
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_25:
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Julian Anastasov <[email protected]>
commit ff75f40f44ae9b79d520bf32a05d35af74a805c0 upstream.
Fix dst_lock usage in __ip_vs_update_dest. We need
_bh locking because destination is updated in user context.
Can cause lockups on frequent destination updates.
Problem reported by Simon Kirby. Bug was introduced
in 2.6.37 from the "ipvs: changes for local real server"
change.
Signed-off-by: Julian Anastasov <[email protected]>
Signed-off-by: Hans Schillstrom <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
Cc: Simon Kirby <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -810,9 +810,9 @@ __ip_vs_update_dest(struct ip_vs_service
dest->u_threshold = udest->u_threshold;
dest->l_threshold = udest->l_threshold;
- spin_lock(&dest->dst_lock);
+ spin_lock_bh(&dest->dst_lock);
ip_vs_dst_reset(dest);
- spin_unlock(&dest->dst_lock);
+ spin_unlock_bh(&dest->dst_lock);
if (add)
ip_vs_new_estimator(&dest->stats);
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Vasiliy Kulikov <[email protected]>
commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b upstream.
Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean
that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't
allow anybody load any module not related to networking.
This patch restricts an ability of autoloading modules to netdev modules
with explicit aliases. This fixes CVE-2011-1019.
Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior
of loading netdev modules by name (without any prefix) for processes
with CAP_SYS_MODULE to maintain the compatibility with network scripts
that use autoloading netdev modules by aliases like "eth0", "wlan0".
Currently there are only three users of the feature in the upstream
kernel: ipip, ip_gre and sit.
root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --
root@albatros:~# grep Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: fffffff800001000
CapEff: fffffff800001000
CapBnd: fffffff800001000
root@albatros:~# modprobe xfs
FATAL: Error inserting xfs
(/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted
root@albatros:~# lsmod | grep xfs
root@albatros:~# ifconfig xfs
xfs: error fetching interface information: Device not found
root@albatros:~# lsmod | grep xfs
root@albatros:~# lsmod | grep sit
root@albatros:~# ifconfig sit
sit: error fetching interface information: Device not found
root@albatros:~# lsmod | grep sit
root@albatros:~# ifconfig sit0
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
root@albatros:~# lsmod | grep sit
sit 10457 0
tunnel4 2957 1 sit
For CAP_SYS_MODULE module loading is still relaxed:
root@albatros:~# grep Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
root@albatros:~# ifconfig xfs
xfs: error fetching interface information: Device not found
root@albatros:~# lsmod | grep xfs
xfs 745319 0
Reference: https://lkml.org/lkml/2011/2/24/203
Signed-off-by: Vasiliy Kulikov <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Acked-by: David S. Miller <[email protected]>
Acked-by: Kees Cook <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/netdevice.h | 3 +++
net/core/dev.c | 12 ++++++++++--
net/ipv4/ip_gre.c | 1 +
net/ipv4/ipip.c | 1 +
net/ipv6/sit.c | 2 +-
5 files changed, 16 insertions(+), 3 deletions(-)
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2336,6 +2336,9 @@ extern int netdev_notice(const struct ne
extern int netdev_info(const struct net_device *dev, const char *format, ...)
__attribute__ ((format (printf, 2, 3)));
+#define MODULE_ALIAS_NETDEV(device) \
+ MODULE_ALIAS("netdev-" device)
+
#if defined(DEBUG)
#define netdev_dbg(__dev, format, args...) \
netdev_printk(KERN_DEBUG, __dev, format, ##args)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1116,13 +1116,21 @@ EXPORT_SYMBOL(netdev_bonding_change);
void dev_load(struct net *net, const char *name)
{
struct net_device *dev;
+ int no_module;
rcu_read_lock();
dev = dev_get_by_name_rcu(net, name);
rcu_read_unlock();
- if (!dev && capable(CAP_NET_ADMIN))
- request_module("%s", name);
+ no_module = !dev;
+ if (no_module && capable(CAP_NET_ADMIN))
+ no_module = request_module("netdev-%s", name);
+ if (no_module && capable(CAP_SYS_MODULE)) {
+ if (!request_module("%s", name))
+ pr_err("Loading kernel module for a network device "
+"with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s "
+"instead\n", name);
+ }
}
EXPORT_SYMBOL(dev_load);
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1775,3 +1775,4 @@ module_exit(ipgre_fini);
MODULE_LICENSE("GPL");
MODULE_ALIAS_RTNL_LINK("gre");
MODULE_ALIAS_RTNL_LINK("gretap");
+MODULE_ALIAS_NETDEV("gre0");
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -921,3 +921,4 @@ static void __exit ipip_fini(void)
module_init(ipip_init);
module_exit(ipip_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_NETDEV("tunl0");
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1292,4 +1292,4 @@ static int __init sit_init(void)
module_init(sit_init);
module_exit(sit_cleanup);
MODULE_LICENSE("GPL");
-MODULE_ALIAS("sit0");
+MODULE_ALIAS_NETDEV("sit0");
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Naga Chumbalkar <[email protected]>
commit 1f858ef2fbabdc5e645644010a31a40c32e397c9 upstream.
Return 0 on failure. This will cause the initialization of the driver
to fail and prevent the driver from loading if the BIOS cannot handle
the PCC interface command to "get frequency". Otherwise, the driver
will load and display a very high value like "4294967274" (which is
actually -EINVAL) for frequency:
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
4294967274
Signed-off-by: Naga Chumbalkar <[email protected]>
Signed-off-by: Dave Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpu/cpufreq/pcc-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/cpufreq/pcc-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/pcc-cpufreq.c
@@ -195,7 +195,7 @@ static unsigned int pcc_get_freq(unsigne
cmd_incomplete:
iowrite16(0, &pcch_hdr->status);
spin_unlock(&pcc_lock);
- return -EINVAL;
+ return 0;
}
static int pcc_cpufreq_target(struct cpufreq_policy *policy,
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Chuck Lever <[email protected]>
commit d1205f87bbb8040c1408bbd9e0a720310b2b0b9b upstream.
On recent 2.6.38-rc kernels, connectathon basic test 6 fails on
NFSv4 mounts of OpenSolaris with something like:
> ./test6: readdir
> ./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.12' dir entry, pass 0
> ./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.82' dir entry, pass 0
> ./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.164' dir entry, pass 0
> ./test6: (/mnt/klimt/matisse.test) Test failed with 3 errors
> basic tests failed
> Tests failed, leaving /mnt/klimt mounted
> [cel@matisse cthon04]$
I narrowed the problem down to nfs4_decode_dirent() reporting that the
decode buffer had overflowed while decoding the entries for those
missing files.
verify_attr_len() assumes both it's pointer arguments reside on the
same page. When these arguments point to locations on two different
pages, verify_attr_len() can report false errors. This can happen now
that a large NFSv4 readdir result can span pages.
We have reasonably good checking in nfs4_decode_dirent() anyway, so
it should be safe to simply remove the extra checking.
At a guess, this was introduced by commit 6650239a, "NFS: Don't use
vm_map_ram() in readdir".
Signed-off-by: Chuck Lever <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/nfs4xdr.c | 3 ---
1 file changed, 3 deletions(-)
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -6212,9 +6212,6 @@ __be32 *nfs4_decode_dirent(struct xdr_st
if (entry->fattr->valid & NFS_ATTR_FATTR_TYPE)
entry->d_type = nfs_umode_to_dtype(entry->fattr->mode);
- if (verify_attr_len(xdr, p, len) < 0)
- goto out_overflow;
-
return p;
out_overflow:
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Benjamin Tissoires <[email protected]>
commit ad6d42670279da8f33f633f8a96a67cd7ef3b1da upstream.
This commit allows the device to be recognized as a touchscreen, and not a
touchpad by xf86-input-evdev.
The device has 2 modes. The first one is an emulation of a touchscreen by
sending left and right button, and the second mode is the one used in
dual-touch (sending trackingID, touch and else).
That's why there is a hid report containing left and right buttons
(9000001 and 9000002). The point is that xorg relies on these fields to
determine if it's a touchpad or a touchscreen.
Clearing the report (return -1) makes xorg detecting it out of the box
as a quite pleasant (dual)touchscreen.
Signed-off-by: Benjamin Tissoires <[email protected]>
Acked-by: Chase Douglas <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Cc: James Sharam <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-mosart.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/hid/hid-mosart.c
+++ b/drivers/hid/hid-mosart.c
@@ -90,6 +90,10 @@ static int mosart_input_mapping(struct h
case 0xff000000:
/* ignore HID features */
return -1;
+
+ case HID_UP_BUTTON:
+ /* ignore buttons */
+ return -1;
}
return 0;
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jan Engelhardt <[email protected]>
commit 9ef0298a8e5730d9a46d640014c727f3b4152870 upstream.
Like many other places, we have to check that the array index is
within allowed limits, or otherwise, a kernel oops and other nastiness
can ensue when we access memory beyond the end of the array.
[ 5954.115381] BUG: unable to handle kernel paging request at 0000004000000000
[ 5954.120014] IP: __find_logger+0x6f/0xa0
[ 5954.123979] nf_log_bind_pf+0x2b/0x70
[ 5954.123979] nfulnl_recv_config+0xc0/0x4a0 [nfnetlink_log]
[ 5954.123979] nfnetlink_rcv_msg+0x12c/0x1b0 [nfnetlink]
...
The problem goes back to v2.6.30-rc1~1372~1342~31 where nf_log_bind
was decoupled from nf_log_register.
Reported-by: Miguel Di Ciurcio Filho <[email protected]>,
via irc.freenode.net/#netfilter
Signed-off-by: Jan Engelhardt <[email protected]>
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/netfilter/nf_log.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -85,6 +85,8 @@ EXPORT_SYMBOL(nf_log_unregister);
int nf_log_bind_pf(u_int8_t pf, const struct nf_logger *logger)
{
+ if (pf >= ARRAY_SIZE(nf_loggers))
+ return -EINVAL;
mutex_lock(&nf_log_mutex);
if (__find_logger(pf, logger->name) == NULL) {
mutex_unlock(&nf_log_mutex);
@@ -98,6 +100,8 @@ EXPORT_SYMBOL(nf_log_bind_pf);
void nf_log_unbind_pf(u_int8_t pf)
{
+ if (pf >= ARRAY_SIZE(nf_loggers))
+ return;
mutex_lock(&nf_log_mutex);
rcu_assign_pointer(nf_loggers[pf], NULL);
mutex_unlock(&nf_log_mutex);
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Anton Blanchard <[email protected]>
commit f009918a1c1bbf8607b8aab3959876913a30193a upstream.
commit 339412841d7 (RxRPC: Allow key payloads to be passed in XDR form)
broke klog for me. I notice the v1 key struct had a kif_version field
added:
-struct rxkad_key {
- u16 security_index; /* RxRPC header security index */
- u16 ticket_len; /* length of ticket[] */
- u32 expiry; /* time at which expires */
- u32 kvno; /* key version number */
- u8 session_key[8]; /* DES session key */
- u8 ticket[0]; /* the encrypted ticket */
-};
+struct rxrpc_key_data_v1 {
+ u32 kif_version; /* 1 */
+ u16 security_index;
+ u16 ticket_length;
+ u32 expiry; /* time_t */
+ u32 kvno;
+ u8 session_key[8];
+ u8 ticket[0];
+};
However the code in rxrpc_instantiate strips it away:
data += sizeof(kver);
datalen -= sizeof(kver);
Removing kif_version fixes my problem.
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: David Howells <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/keys/rxrpc-type.h | 1 -
1 file changed, 1 deletion(-)
--- a/include/keys/rxrpc-type.h
+++ b/include/keys/rxrpc-type.h
@@ -99,7 +99,6 @@ struct rxrpc_key_token {
* structure of raw payloads passed to add_key() or instantiate key
*/
struct rxrpc_key_data_v1 {
- u32 kif_version; /* 1 */
u16 security_index;
u16 ticket_length;
u32 expiry; /* time_t */
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Hugh Dickins <[email protected]>
commit a3e8cc643d22d2c8ed36b9be7d9c9ca21efcf7f7 upstream.
Robert Swiecki reported a BUG_ON(page_mapped) from a fuzzer, punching
a hole with madvise(,, MADV_REMOVE). That path is under mutex, and
cannot be explained by lack of serialization in unmap_mapping_range().
Reviewing the code, I found one place where vm_truncate_count handling
should have been updated, when I switched at the last minute from one
way of managing the restart_addr to another: mremap move changes the
virtual addresses, so it ought to adjust the restart_addr.
But rather than exporting the notion of restart_addr from memory.c, or
converting to restart_pgoff throughout, simply reset vm_truncate_count
to 0 to force a rescan if mremap move races with preempted truncation.
We have no confirmation that this fixes Robert's BUG,
but it is a fix that's worth making anyway.
Signed-off-by: Hugh Dickins <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Kerin Millar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/mremap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -91,9 +91,7 @@ static void move_ptes(struct vm_area_str
*/
mapping = vma->vm_file->f_mapping;
spin_lock(&mapping->i_mmap_lock);
- if (new_vma->vm_truncate_count &&
- new_vma->vm_truncate_count != vma->vm_truncate_count)
- new_vma->vm_truncate_count = 0;
+ new_vma->vm_truncate_count = 0;
}
/*
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Don Skidmore <[email protected]>
commit a124339ad28389093ed15eca990d39c51c5736cc upstream.
We have found a hardware erratum on 82599 hardware that can lead to
unpredictable behavior when Header Splitting mode is enabled. So
we are no longer enabling this feature on affected hardware.
Please see the 82599 Specification Update for more information.
Signed-off-by: Don Skidmore <[email protected]>
Tested-by: Stephen Ko <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ixgbe/ixgbe_main.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2923,6 +2923,10 @@ static void ixgbe_set_rx_buffer_len(stru
if (hw->mac.type == ixgbe_mac_82599EB)
adapter->flags &= ~IXGBE_FLAG_RX_PS_ENABLED;
+ /* Disable packet split due to 82599 erratum #45 */
+ if (hw->mac.type == ixgbe_mac_82599EB)
+ adapter->flags &= ~IXGBE_FLAG_RX_PS_ENABLED;
+
/* Set the RX buffer length according to the mode */
if (adapter->flags & IXGBE_FLAG_RX_PS_ENABLED) {
rx_buf_len = IXGBE_RX_HDR_SIZE;
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mohammed Shafi Shajakhan <[email protected]>
This is a backport of upstream commit 0f5cd45960173ba5b36727decbb4a241cbd35ef9.
The DMA latency issue is observed only in Intel pinetrail platforms
but in the driver we had a default PM-QOS value of 55. This caused
unnecessary power consumption and battery drain in other platforms.
Remove the pm-qos thing in the driver code and address the throughput
issue in Intel pinetrail platfroms in user space using any one of
the scripts in below links:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/scripts/cpudmalatency.c
http://johannes.sipsolutions.net/files/netlatency.c.txt
More details can be found in the following bugzilla link:
https://bugzilla.kernel.org/show_bug.cgi?id=27532
Signed-off-by: Thomas B?chler <[email protected]>
Acked-by: Mohammed Shafi Shajakhan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 3 ---
drivers/net/wireless/ath/ath9k/init.c | 4 ----
drivers/net/wireless/ath/ath9k/main.c | 4 ----
3 files changed, 11 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -21,7 +21,6 @@
#include <linux/device.h>
#include <linux/leds.h>
#include <linux/completion.h>
-#include <linux/pm_qos_params.h>
#include "debug.h"
#include "common.h"
@@ -647,8 +646,6 @@ struct ath_softc {
struct ath_descdma txsdma;
struct ath_ant_comb ant_comb;
-
- struct pm_qos_request_list pm_qos_req;
};
struct ath_wiphy {
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -758,9 +758,6 @@ int ath9k_init_device(u16 devid, struct
ath_init_leds(sc);
ath_start_rfkill_poll(sc);
- pm_qos_add_request(&sc->pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
- PM_QOS_DEFAULT_VALUE);
-
return 0;
error_world:
@@ -829,7 +826,6 @@ void ath9k_deinit_device(struct ath_soft
}
ieee80211_unregister_hw(hw);
- pm_qos_remove_request(&sc->pm_qos_req);
ath_rx_cleanup(sc);
ath_tx_cleanup(sc);
ath9k_deinit_softc(sc);
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1245,8 +1245,6 @@ static int ath9k_start(struct ieee80211_
ath9k_btcoex_timer_resume(sc);
}
- pm_qos_update_request(&sc->pm_qos_req, 55);
-
mutex_unlock:
mutex_unlock(&sc->mutex);
@@ -1425,8 +1423,6 @@ static void ath9k_stop(struct ieee80211_
sc->sc_flags |= SC_OP_INVALID;
- pm_qos_update_request(&sc->pm_qos_req, PM_QOS_DEFAULT_VALUE);
-
mutex_unlock(&sc->mutex);
ath_print(common, ATH_DBG_CONFIG, "Driver halt\n");
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Axel Lin <[email protected]>
commit 97e419a082461f8a3a0818834eb88ad41219a1da upstream.
The device table is required to load modules based on modaliases.
Signed-off-by: Axel Lin <[email protected]>
Cc: Shubhrajyoti D <[email protected]>
Cc: Christoph Mair <[email protected]>
Cc: Jonathan Cameron <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/misc/bmp085.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/misc/bmp085.c
+++ b/drivers/misc/bmp085.c
@@ -449,6 +449,7 @@ static const struct i2c_device_id bmp085
{ "bmp085", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, bmp085_id);
static struct i2c_driver bmp085_driver = {
.driver = {
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Mark Brown <[email protected]>
commit 3ee845acba58549578d03a46ed307c0a56c7f777 upstream.
It went AWOL in the multi-component conversion.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/wm9081.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/sound/soc/codecs/wm9081.c
+++ b/sound/soc/codecs/wm9081.c
@@ -15,6 +15,7 @@
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/delay.h>
+#include <linux/device.h>
#include <linux/pm.h>
#include <linux/i2c.h>
#include <linux/platform_device.h>
@@ -1338,6 +1339,10 @@ static __devinit int wm9081_i2c_probe(st
wm9081->control_type = SND_SOC_I2C;
wm9081->control_data = i2c;
+ if (dev_get_platdata(&i2c->dev))
+ memcpy(&wm9081->retune, dev_get_platdata(&i2c->dev),
+ sizeof(wm9081->retune));
+
ret = snd_soc_register_codec(&i2c->dev,
&soc_codec_dev_wm9081, &wm9081_dai, 1);
if (ret < 0)
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Takashi Iwai <[email protected]>
commit 38c07641905c0db58e800ea974cd9158717c6610 upstream.
The errata init verbs for CS42xx codecs contain the verbs to set
the power-state of SPDIF nodes to D3, which seem to break the SPDIF
output on some MacBooks. Since this is executed during the power-up
initialization, we shouldn't turn them down there.
Reported-by: Arun Raghavan <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_cirrus.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -1039,9 +1039,11 @@ static struct hda_verb cs_errata_init_ve
{0x11, AC_VERB_SET_PROC_COEF, 0x0008},
{0x11, AC_VERB_SET_PROC_STATE, 0x00},
+#if 0 /* Don't to set to D3 as we are in power-up sequence */
{0x07, AC_VERB_SET_POWER_STATE, 0x03}, /* S/PDIF Rx: D3 */
{0x08, AC_VERB_SET_POWER_STATE, 0x03}, /* S/PDIF Tx: D3 */
/*{0x01, AC_VERB_SET_POWER_STATE, 0x03},*/ /* AFG: D3 This is already handled */
+#endif
{} /* terminator */
};
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Henningsson <[email protected]>
commit f0ce27996217d06207c8bfda1b1bbec2fbab48c6 upstream.
This patch fixes an error in the jack detection reporting,
causing the jack detection sometimes not to be reported
correctly to the input subsystem. It should apply to several
Realtek codecs.
Signed-off-by: David Henningsson <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/hda/patch_realtek.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -1127,11 +1127,8 @@ static void alc_automute_speaker(struct
nid = spec->autocfg.hp_pins[i];
if (!nid)
break;
- if (snd_hda_jack_detect(codec, nid)) {
- spec->jack_present = 1;
- break;
- }
- alc_report_jack(codec, spec->autocfg.hp_pins[i]);
+ alc_report_jack(codec, nid);
+ spec->jack_present |= snd_hda_jack_detect(codec, nid);
}
mute = spec->jack_present ? HDA_AMP_MUTE : 0;
2.6.37-stable review patch. If anyone has any objections, please let us know.
------------------
From: Amit Shah <[email protected]>
commit d7a62cd0332115d4c7c4689abea0d889a30d8349 upstream.
If a virtio-console device gets unplugged while a port is open, a
subsequent close() call on the port accesses vqs to free up buffers.
This can lead to a crash.
The buffers are already freed up as a result of the call to
unplug_ports() from virtcons_remove(). The fix is to simply not access
vq information if port->portdev is NULL.
Reported-by: juzhang <[email protected]>
Signed-off-by: Amit Shah <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/virtio_console.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -387,6 +387,10 @@ static void discard_port_data(struct por
unsigned int len;
int ret;
+ if (!port->portdev) {
+ /* Device has been unplugged. vqs are already gone. */
+ return;
+ }
vq = port->in_vq;
if (port->inbuf)
buf = port->inbuf;
@@ -469,6 +473,10 @@ static void reclaim_consumed_buffers(str
void *buf;
unsigned int len;
+ if (!port->portdev) {
+ /* Device has been unplugged. vqs are already gone. */
+ return;
+ }
while ((buf = virtqueue_get_buf(port->out_vq, &len))) {
kfree(buf);
port->outvq_full = false;
Hi
On Friday 11 March 2011, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.37.r release.
> There are 29 patches in this series, all will be posted as a response to
> this one. If anyone has any issues with these being applied, please let
> us know. If anyone is a maintainer of the proper subsystem, and wants
> to add a Signed-off-by: line to the patch, please respond with it.
>
> Responses should be made by Saturday, March 12, 24:00:00 UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.37.4-rc1.gz
This seems to be still missing on kernel.org, is there an issue with
the mirroring?
$ LANG= wget kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.37.4-rc1.gz
--2011-03-11 16:01:24-- http://kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.37.4-rc1.gz
Resolving kernel.org... 130.239.17.4, 149.20.20.133, 199.6.1.164, ...
Connecting to kernel.org|130.239.17.4|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2011-03-11 16:01:24 ERROR 404: Not Found.
Regards
Stefan Lippers-Hollmann
On Fri, Mar 11, 2011 at 04:02:02PM +0100, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Friday 11 March 2011, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.37.r release.
> > There are 29 patches in this series, all will be posted as a response to
> > this one. If anyone has any issues with these being applied, please let
> > us know. If anyone is a maintainer of the proper subsystem, and wants
> > to add a Signed-off-by: line to the patch, please respond with it.
> >
> > Responses should be made by Saturday, March 12, 24:00:00 UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.37.4-rc1.gz
>
> This seems to be still missing on kernel.org, is there an issue with
> the mirroring?
>
> $ LANG= wget kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.37.4-rc1.gz
> --2011-03-11 16:01:24-- http://kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.37.4-rc1.gz
> Resolving kernel.org... 130.239.17.4, 149.20.20.133, 199.6.1.164, ...
> Connecting to kernel.org|130.239.17.4|:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2011-03-11 16:01:24 ERROR 404: Not Found.
Sorry, right after I sent out this announcement, the power went out here
where I live, and when it came on 3 hours later, the network wasn't back
on until this morning. The file is now copied there and should show up
on the mirrors within 30 minutes.
thanks,
greg k-h