linux-toradex.git, branch v3.7.6

Linux 3.7.6

2013-02-04T00:27:30+00:00

netfilter: xt_CT: fix unset return value if conntrack zone are disabled

2013-02-04T00:27:08+00:00

commit 4610476d89d53714ca94aae081fa035908bc137a upstream.

net/netfilter/xt_CT.c: In function ‘xt_ct_tg_check_v1’:
net/netfilter/xt_CT.c:250:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]
net/netfilter/xt_CT.c: In function ‘xt_ct_tg_check_v0’:
net/netfilter/xt_CT.c:112:6: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Reported-by: Borislav Petkov 
Acked-by: Borislav Petkov 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

slub: assign refcount for kmalloc_caches

2013-02-04T00:27:08+00:00

This is for stable-3.7.y only and this problem has already been solved
in mainline through some slab/slub re-work which isn't suitable to
backport here. See create_kmalloc_cache() in mm/slab_common.c there.

commit cce89f4f6911286500cf7be0363f46c9b0a12ce0('Move kmem_cache
refcounting to common code') moves some refcount manipulation code to
common code. Unfortunately, it also removed refcount assignment for
kmalloc_caches. So, kmalloc_caches's refcount is initially 0.
This makes erroneous situation.

Paul Hargrove report that when he create a 8-byte kmem_cache and
destory it, he encounter below message.
'Objects remaining in kmalloc-8 on kmem_cache_close()'

8-byte kmem_cache merge with 8-byte kmalloc cache and refcount is
increased by one. So, resulting refcount is 1. When destroy it, it hit
refcount = 0, then kmem_cache_close() is executed and error message is
printed.

This patch assign initial refcount 1 to kmalloc_caches, so fix this
erroneous situation.

Reported-by: Paul Hargrove 
Cc: Christoph Lameter 
Signed-off-by: Joonsoo Kim 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix FORCEWAKE posting reads

2013-02-04T00:27:08+00:00

commit b514407547890686572606c9dfa4b7f832db9958 upstream.

We stopped reading FORCEWAKE for posting reads in

commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd
Author: Ben Widawsky 
Date:   Sat Sep 1 22:59:50 2012 -0700

    drm/i915: Never read FORCEWAKE

and started using something from the same cacheline instead. On the
bug reporter's machine this broke entering rc6 states after a
suspend/resume cycle. It turns out reading ECOBUS as posting read
worked fine, while GTFIFODBG did not, preventing RC6 states after
suspend/resume per the bug report referenced below. It's not entirely
clear why, but clearly GTFIFODBG was nowhere near the same cacheline
or address range as FORCEWAKE.

Trying out various registers for posting reads showed that all tested
registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true
work. Conversely, most (but not quite all) registers for which
NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced
bug.

Based on the above, add posting reads on ECOBUS where GTFIFODBG was
previously relied on.

In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as
well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same
address range as FORCEWAKE_VLV.

v2: Add more details to the commit message. No functional changes.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411
Reported-and-tested-by: Alexander Bersenev 
CC: Ben Widawsky 
Signed-off-by: Jani Nikula 
Reviewed-by: Chris Wilson 
Cc: stable@vger.kernel.org
[danvet: add cc: stable and make the commit message a bit clearer that
this is a regression fix and what exactly broke.]
Signed-off-by: Daniel Vetter 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

netfilter: ctnetlink: fix leak in error path of ctnetlink_create_expect

2013-02-04T00:27:08+00:00

commit 1310b955c804975651dca6c674ebfd1cb2b4c7ff upstream.

This patch fixes a leak in one of the error paths of
ctnetlink_create_expect if no helper and no timeout is specified.

Signed-off-by: Jesper Juhl 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: x_tables: print correct hook names for ARP

2013-02-04T00:27:08+00:00

commit 5b76c4948fe6977bead2359c2054f3e6a2dcf3d0 upstream.

arptables 0.0.4 (released on 10th Jan 2013) supports calling the
CLASSIFY target, but on adding a rule to the wrong chain, the
diagnostic is as follows:

	# arptables -A INPUT -j CLASSIFY --set-class 0:0
	arptables: Invalid argument
	# dmesg | tail -n1
	x_tables: arp_tables: CLASSIFY target: used from hooks
	PREROUTING, but only usable from INPUT/FORWARD

This is incorrect, since xt_CLASSIFY.c does specify
(1 << NF_ARP_OUT) | (1 << NF_ARP_FORWARD).

This patch corrects the x_tables diagnostic message to print the
proper hook names for the NFPROTO_ARP case.

Affects all kernels down to and including v2.6.31.

Signed-off-by: Jan Engelhardt 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns

2013-02-04T00:27:08+00:00

commit 1e47ee8367babe6a5e8adf44a714c7086657b87e upstream.

canqun zhang reported that we're hitting BUG_ON in the
nf_conntrack_destroy path when calling kfree_skb while
rmmod'ing the nf_conntrack module.

Currently, the nf_ct_destroy hook is being set to NULL in the
destroy path of conntrack.init_net. However, this is a problem
since init_net may be destroyed before any other existing netns
(we cannot assume any specific ordering while releasing existing
netns according to what I read in recent emails).

Thanks to Gao feng for initial patch to address this issue.

Reported-by: canqun zhang 
Acked-by: Gao feng 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_recent: avoid high order page allocations

2013-02-04T00:27:08+00:00

commit 2727de76041b2064c0b74f00a2a89678fb3efafc upstream.

xt_recent can try high order page allocations and this can fail.

iptables: page allocation failure: order:9, mode:0xc0d0

It also wastes about half the allocated space because of kmalloc()
power-of-two roundups and struct recent_table layout.

Use vmalloc() instead to save space and be less prone to allocation
errors when memory is fragmented.

Reported-by: Miroslav Kratochvil 
Reported-by: Dave Jones 
Reported-by: Harald Reindl 
Signed-off-by: Eric Dumazet 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_recent: fix namespace destroy path

2013-02-04T00:27:08+00:00

commit 665e205c16c1f902ac6763b8ce8a0a3a1dcefe59 upstream.

recent_net_exit() is called before recent_mt_destroy() in the
destroy path of network namespaces. Make sure there are no entries
in the parent proc entry xt_recent before removing it.

Signed-off-by: Vitaly E. Lavrov 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_hashlimit: fix race that results in duplicated entries

2013-02-04T00:27:07+00:00

commit 09181842b000344b1205801df3aa5b726c03cc62 upstream.

Two packets may race to create the same entry in the hashtable,
double check if this packet lost race. This double checking only
happens in the path of the packet that creates the hashtable for
first time.

Note that, with this patch, no packet drops occur if the race happens.

Reported-by: Feng Gao 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman