Alex Bligh [Tue, 20 Mar 2012 23:48:01 +0000 (10:48 +1100)]
net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy
Problem:
A repeatable Oops can be caused if a container with networking
unshared is destroyed when it has nf_conntrack entries yet to expire.
A copy of the oops follows below. A perl program generating the oops
repeatably is attached inline below.
Analysis:
The oops is called from cleanup_net when the namespace is
destroyed. conntrack iterates through outstanding events and calls
death_by_timeout on each of them, which in turn produces a call to
ctnetlink_conntrack_event. This calls nf_netlink_has_listeners, which
oopses because net->nfnl is NULL.
The perl program generates the container through fork() then
clone(NS_NEWNET). I does not explicitly set up netlink
explicitly set up netlink, but I presume it was set up else net->nfnl
would have been NULL earlier (i.e. when an earlier connection
timed out). This would thus suggest that net->nfnl is made NULL
during the destruction of the container, which I think is done by
nfnetlink_net_exit_batch.
I can see that the various subsystems are deinitialised in the opposite
order to which the relevant register_pernet_subsys calls are called,
and both nf_conntrack and nfnetlink_net_ops register their relevant
subsystems. If nfnetlink_net_ops registered later than nfconntrack,
then its exit routine would have been called first, which would cause
the oops described. I am not sure there is anything to prevent this
happening in a container environment.
Whilst there's perhaps a more complex problem revolving around ordering
of subsystem deinit, it seems to me that missing a netlink event on a
container that is dying is not a disaster. An early check for net->nfnl
being non-NULL in ctnetlink_conntrack_event appears to fix this. There
may remain a potential race condition if it becomes NULL immediately
after being checked (I am not sure any lock is held at this point or
how synchronisation for subsystem deinitialization works).
Patch:
The patch attached should apply on everything from 2.6.26 (if not before)
onwards; it appears to be a problem on all kernels. This was taken against
Ubuntu-3.0.0-11.17 which is very close to 3.0.4. I have torture-tested it
with the above perl script for 15 minutes or so; the perl script hung the
machine within 20 seconds without this patch.
Applicability:
If this is the right solution, it should be applied to all stable kernels
as well as head. Apart from the minor overhead of checking one variable
against NULL, it can never 'do the wrong thing', because if net->nfnl
is NULL, an oops will inevitably result. Therefore, checking is a reasonable
thing to do unless it can be proven than net->nfnl will never be NULL.
Check net->nfnl for NULL in ctnetlink_conntrack_event to avoid Oops on
container destroy
Signed-off-by: Alex Bligh <alex@alex.org.uk> Cc: Patrick McHardy <kaber@trash.net> Cc: David Miller <davem@davemloft.net> Cc: <stable@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ipv6: Fix RTM_GETROUTE's interpretation of RTA_IIF to be consistent with ipv4
In IPv4, if an RTA_IIF attribute is specified within an RTM_GETROUTE
message, then a route is searched as if a packet was received on the
specified 'iif' interface.
However in IPv6, RTA_IIF is not interpreted in the same way:
'inet6_rtm_getroute()' always calls 'ip6_route_output()', regardless the
RTA_IIF attribute.
As a result, in IPv6 there's no way to use RTM_GETROUTE in order to look
for a route as if a packet was received on a specific interface.
Fix 'inet6_rtm_getroute()' so that RTA_IIF is interpreted as "lookup a
route as if a packet was received on the specified interface", similar
to IPv4's 'inet_rtm_getroute()' interpretation.
Reported-by: Ami Koren <amikoren@yahoo.com> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Aaro Koskinen [Sun, 1 Apr 2012 08:54:38 +0000 (08:54 +0000)]
sparc: pgtable_64: change include order
Fix the following build breakage in v3.4-rc1:
CC arch/sparc/kernel/cpu.o
In file included from /home/aaro/git/linux/arch/sparc/include/asm/pgtable_64.h:15:0,
from /home/aaro/git/linux/arch/sparc/include/asm/pgtable.h:4,
from arch/sparc/kernel/cpu.c:15:
include/asm-generic/pgtable-nopud.h:13:16: error: unknown type name 'pgd_t'
include/asm-generic/pgtable-nopud.h:25:28: error: unknown type name 'pgd_t'
include/asm-generic/pgtable-nopud.h:26:27: error: unknown type name 'pgd_t'
include/asm-generic/pgtable-nopud.h:27:31: error: unknown type name 'pgd_t'
include/asm-generic/pgtable-nopud.h:28:30: error: unknown type name 'pgd_t'
include/asm-generic/pgtable-nopud.h:38:34: error: unknown type name 'pgd_t'
In file included from /home/aaro/git/linux/arch/sparc/include/asm/pgtable_64.h:783:0,
from /home/aaro/git/linux/arch/sparc/include/asm/pgtable.h:4,
from arch/sparc/kernel/cpu.c:15:
include/asm-generic/pgtable.h: In function 'pgd_none_or_clear_bad':
include/asm-generic/pgtable.h:258:2: error: implicit declaration of function 'pgd_none' [-Werror=implicit-function-declaration]
include/asm-generic/pgtable.h:260:2: error: implicit declaration of function 'pgd_bad' [-Werror=implicit-function-declaration]
include/asm-generic/pgtable.h: In function 'pud_none_or_clear_bad':
include/asm-generic/pgtable.h:269:6: error: request for member 'pgd' in something not a structure or union
Reported-by: Meelis Roos <mroos@linux.ee> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
Remove casts and use proper printf()-style format specifiers instead.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: David S. Miller <davem@davemloft.net> Cc: netdev@vger.kernel.org Acked-by: David S. Miller <davem@davemloft.net>
CC init/main.o
In file included from include/linux/mm.h:15:0,
from include/linux/ring_buffer.h:5,
from include/linux/ftrace_event.h:4,
from include/trace/syscall.h:6,
from include/linux/syscalls.h:78,
from init/main.c:16:
include/linux/debug_locks.h: In function ‘__debug_locks_off’:
include/linux/debug_locks.h:16:2: error: implicit declaration of function ‘xchg’
There is no indirect inclusions of the new asm/cmpxchg.h for m68k here.
Looking at most other architectures they include asm/cmpxchg.h in their
asm/atomic.h. M68k currently does not do this. Including this in atomic.h
fixes all m68k build problems.
stigge@antcom.de [Wed, 28 Mar 2012 12:36:26 +0000 (12:36 +0000)]
net: lpc_eth: Fix rename of dev_hw_addr_random
In parallel to the integration of lpc_eth.c, dev_hw_addr_random() has been
renamed to eth_hw_addr_random(). This patch fixes it also in the new driver
lpc_eth.c.
Signed-off-by: Roland Stigge <stigge@antcom.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew Morton [Wed, 28 Mar 2012 12:10:57 +0000 (12:10 +0000)]
net/netfilter/nfnetlink_acct.c: use linux/atomic.h
There's no known problem here, but this is one of only two non-arch files
in the kernel which use asm/atomic.h instead of linux/atomic.h.
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Patrick McHardy <kaber@trash.net> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
If both addresses equal, nothing needs to be done. If the device is down,
then we simply copy the new address to dev->dev_addr. If the device is up,
then we add another loopback device with the new address, and if that does
not fail, we remove the loopback device with the old address. And only
then, we update the dev->dev_addr.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
Kenth Eriksson [Tue, 27 Mar 2012 22:05:54 +0000 (22:05 +0000)]
Fix non TBI PHY access; a bad merge undid bug fix in a previous commit.
The merge done in commit b26e478f undid bug fix in commit c3e072f8
("net: fsl_pq_mdio: fix non tbi phy access"), with the result that non
TBI (e.g. MDIO) PHYs cannot be accessed.
Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Ward [Tue, 27 Mar 2012 09:01:52 +0000 (09:01 +0000)]
net/garp: avoid infinite loop if attribute already exists
An infinite loop occurred if garp_attr_create was called with the values
of an existing attribute. This might happen if a previous leave request
for the attribute has not yet been followed by a PDU transmission (or,
if the application previously issued a join request for the attribute
and is now issuing another one, without having issued a leave request).
If garp_attr_create finds an existing attribute having the same values,
return the address to it. Its state will then get updated (i.e., if it
was in a leaving state, it will move into a non-leaving state and not
get deleted during the next PDU transmission).
To accomplish this fix, collapse garp_attr_insert into garp_attr_create
(which is its only caller).
Thanks to Jorge Boncompte [DTI2] <jorge@dti2.net> for contributing to
this fix.
Signed-off-by: David Ward <david.ward@ll.mit.edu> Acked-by: Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Paul Gortmaker [Sun, 1 Apr 2012 18:41:36 +0000 (14:41 -0400)]
asm-generic: add linux/types.h to cmpxchg.h
Builds of the openrisc or1ksim_defconfig show the following:
In file included from arch/openrisc/include/generated/asm/cmpxchg.h:1:0,
from include/asm-generic/atomic.h:18,
from arch/openrisc/include/generated/asm/atomic.h:1,
from include/linux/atomic.h:4,
from include/linux/dcache.h:4,
from fs/notify/fsnotify.c:19:
include/asm-generic/cmpxchg.h: In function '__xchg':
include/asm-generic/cmpxchg.h:34:20: error: expected ')' before 'u8'
include/asm-generic/cmpxchg.h:34:20: warning: type defaults to 'int' in type name
and many more lines of similar errors. It seems specific to the or32
because most other platforms have an arch specific component that would
have already included types.h ahead of time, but the o32 does not.
Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jonas Bonn <jonas@southpole.se> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
"device.h: audit and cleanup users in main include dir"
exchanged an include <linux/device.h> for a struct *device
but in actuality I misread this file when creating 313162d
and it should have remained an include.
There were no build regressions since all consumers were
already getting device.h anyway, but make it right regardless.
Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Paul Gortmaker [Sun, 1 Apr 2012 17:45:53 +0000 (13:45 -0400)]
frv: fix warnings in mb93090-mb00/pci-dma.c about implicit EXPORT_SYMBOL
To fix:
arch/frv/mb93090-mb00/pci-dma.c:31:1: warning: data definition has no type or storage class [enabled by default]
arch/frv/mb93090-mb00/pci-dma.c:31:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
arch/frv/mb93090-mb00/pci-dma.c:31:1: warning: parameter names (without types) in function declaration [enabled by default]
arch/frv/mb93090-mb00/pci-dma.c:38:1: warning: data definition has no type or storage class [enabled by default]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
created the new file asm/cache_insns.h but it didn't add
an include for all the users of it.
The failure on fpu.c (also seen below) showed up roughly
at the same time, and since the fix is trivial (include traps.h)
I did not bother to bisect to 100% confirm it was caused by
the system.h disintegration.
arch/sh/mm/flush-sh4.c:16:2: error: implicit declaration of function 'register_align' [-Werror=implicit-function-declaration]
arch/sh/mm/flush-sh4.c:23:3: error: implicit declaration of function '__ocbwb' [-Werror=implicit-function-declaration]
arch/sh/mm/flush-sh4.c:57:3: error: implicit declaration of function '__ocbp' [-Werror=implicit-function-declaration]
arch/sh/mm/flush-sh4.c:87:3: error: implicit declaration of function '__ocbi' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make[2]: *** [arch/sh/mm/flush-sh4.o] Error 1
arch/sh/mm/cache-sh4.c:70:3: error: implicit declaration of function '__ocbwb' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make[2]: *** [arch/sh/mm/cache-sh4.o] Error 1
arch/sh/kernel/cpu/fpu.c:81:2: error: 'TRAP_HANDLER_DECL' undeclared (first use in this function)
arch/sh/kernel/cpu/fpu.c:83:20: error: 'regs' undeclared (first use in this function)
arch/sh/kernel/cpu/fpu.c:83:19: error: called object 'fpu_state_restore' is not a function
make[3]: *** [arch/sh/kernel/cpu/fpu.o] Error 1
arch/sh/kernel/cpu/sh4/fpu.c:407:2: error: 'TRAP_HANDLER_DECL' undeclared (first use in this function)
arch/sh/kernel/cpu/sh4/fpu.c:409:20: error: 'regs' undeclared (first use in this function)
make[4]: *** [arch/sh/kernel/cpu/sh4/fpu.o] Error 1
Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
cgroup: make css->refcnt clearing on cgroup removal optional
Currently, cgroup removal tries to drain all css references. If there
are active css references, the removal logic waits and retries
->pre_detroy() until either all refs drop to zero or removal is
cancelled.
This semantics is unusual and adds non-trivial complexity to cgroup
core and IMHO is fundamentally misguided in that it couples internal
implementation details (references to internal data structure) with
externally visible operation (rmdir). To userland, this is a behavior
peculiarity which is unnecessary and difficult to expect (css refs is
otherwise invisible from userland), and, to policy implementations,
this is an unnecessary restriction (e.g. blkcg wants to hold css refs
for caching purposes but can't as that becomes visible as rmdir hang).
Unfortunately, memcg currently depends on ->pre_destroy() retrials and
cgroup removal vetoing and can't be immmediately switched to the new
behavior. This patch introduces the new behavior of not waiting for
css refs to drain and maintains the old behavior for subsystems which
have __DEPRECATED_clear_css_refs set.
Once, memcg is updated, we can drop the code paths for the old
behavior as proposed in the following patch. Note that the following
patch is incorrect in that dput work item is in cgroup and may lose
some of dputs when multiples css's are released back-to-back, and
__css_put() triggers check_for_release() when refcnt reaches 0 instead
of 1; however, it shows what part can be removed.
Note that, in not-too-distant future, cgroup core will start emitting
warning messages for subsys which require the old behavior, so please
get moving.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Balbir Singh <bsingharora@gmail.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
cgroup: use negative bias on css->refcnt to block css_tryget()
When a cgroup is about to be removed, cgroup_clear_css_refs() is
called to check and ensure that there are no active css references.
This is currently achieved by dropping the refcnt to zero iff it has
only the base ref. If all css refs could be dropped to zero, ref
clearing is successful and CSS_REMOVED is set on all css. If not, the
base ref is restored. While css ref is zero w/o CSS_REMOVED set, any
css_tryget() attempt on it busy loops so that they are atomic
w.r.t. the whole css ref clearing.
This does work but dropping and re-instating the base ref is somewhat
hairy and makes it difficult to add more logic to the put path as
there are two of them - the regular css_put() and the reversible base
ref clearing.
This patch updates css ref clearing such that blocking new
css_tryget() and putting the base ref are separate operations.
CSS_DEACT_BIAS, defined as INT_MIN, is added to css->refcnt and
css_tryget() busy loops while refcnt is negative. After all css refs
are deactivated, if they were all one, ref clearing succeeded and
CSS_REMOVED is set and the base ref is put using the regular
css_put(); otherwise, CSS_DEACT_BIAS is subtracted from the refcnts
and the original postive values are restored.
css_refcnt() accessor which always returns the unbiased positive
reference counts is added and used to simplify refcnt usages. While
at it, relocate and reformat comments in cgroup_has_css_refs().
This separates css->refcnt deactivation and putting the base ref,
which enables the next patch to make ref clearing optional.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Li Zefan <lizf@cn.fujitsu.com>
Implement cgroup_rm_cftypes() which removes an array of cftypes from a
subsystem. It can be called whether the target subsys is attached or
not. cgroup core will remove the specified file from all existing
cgroups.
This will be used to improve sub-subsys modularity and will be helpful
for unified hierarchy.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Li Zefan <lizf@cn.fujitsu.com>
This patch adds cfent (cgroup file entry) which is the association
between a cgroup and a file. This is in-cgroup representation of
files under a cgroup directory. This simplifies walking walking
cgroup files and thus cgroup_clear_directory(), which is now
implemented in two parts - cgroup_rm_file() and a loop around it.
cgroup_rm_file() will be used to implement cftype removal and cfent is
scheduled to serve cgroup specific per-file data (e.g. for sysfs-like
"sever" semantics).
v2: - cfe was freed from cgroup_rm_file() which led to use-after-free
if the file had openers at the time of removal. Moved to
cgroup_diput().
- cgroup_clear_directory() triggered WARN_ON_ONCE() if d_subdirs
wasn't empty after removing all files. This triggered
spuriously if some files were open during directory clearing.
Removed.
v3: - In cgroup_diput(), WARN_ONCE(!list_empty(&cfe->node)) could be
spuriously triggered for root cgroups because they don't go
through cgroup_clear_directory() on unmount. Don't trigger WARN
for root cgroups.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Glauber Costa <glommer@parallels.com>
projects / karo-tx-linux.git / log