With create/mkdir/mknod in non cached mode we initialize the inode using
v9fs_get_inode. v9fs_get_inode doesn't initialize the cache inode value
to NULL. This is causing to trip on BUG_ON in v9fs_get_cached_acl.
Fix is to initialize acls to NULL and not to leave them in ACL_NOT_CACHED
state.
Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
In v9fs_get_acl() if __v9fs_get_acl() gets only one of the
dacl/pacl we are not releasing it.
Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Structures ip6t_replace, compat_ip6t_replace, and xt_get_revision are
copied from userspace. Fields of these structs that are
zero-terminated strings are not checked. When they are used as argument
to a format string containing "%s" in request_module(), some sensitive
information is leaked to userspace via argument of spawned modprobe
process.
The first bug was introduced before the git epoch; the second was
introduced in 3bc3fe5e (v2.6.25-rc1); the third is introduced by
6b7d31fc (v2.6.15-rc1). To trigger the bug one should have
CAP_NET_ADMIN.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Structures ipt_replace, compat_ipt_replace, and xt_get_revision are
copied from userspace. Fields of these structs that are
zero-terminated strings are not checked. When they are used as argument
to a format string containing "%s" in request_module(), some sensitive
information is leaked to userspace via argument of spawned modprobe
process.
The first and the third bugs were introduced before the git epoch; the
second was introduced in 2722971c (v2.6.17-rc1). To trigger the bug
one should have CAP_NET_ADMIN.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Structures ipt_replace, compat_ipt_replace, and xt_get_revision are
copied from userspace. Fields of these structs that are
zero-terminated strings are not checked. When they are used as argument
to a format string containing "%s" in request_module(), some sensitive
information is leaked to userspace via argument of spawned modprobe
process.
The first bug was introduced before the git epoch; the second is
introduced by 6b7d31fc (v2.6.15-rc1); the third is introduced by
6b7d31fc (v2.6.15-rc1). To trigger the bug one should have
CAP_NET_ADMIN.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
A potential race condition when generating connlimit_rnd is also fixed.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
We use the reply tuples when limiting the connections by the destination
addresses, however, in SNAT scenario, the final reply tuples won't be
ready until SNAT is done in POSTROUING or INPUT chain, and the following
nf_conntrack_find_get() in count_tem() will get nothing, so connlimit
can't work as expected.
In this patch, the original tuples are always used, and an additional
member addr is appended to save the address in either end.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
The EDGE Port module of some ColdFire parts using the intc-simr interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The EDGE Port module of some ColdFire parts using the intc-2 interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The reality is that you do not need the abiltity to configure the
clock divider for ColdFire CPUs. It is a fixed ratio on any given
ColdFire family member. It is not the same for all ColdFire parts,
but it is always the same in a model range. So hard define the divider
for each supported ColdFire CPU type and remove the Kconfig option.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/5407/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5407/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5407/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/532x/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/532x/gpio.c:54:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/5307/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5307/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5307/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/527x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:38:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:39:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:54:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/527x/gpio.c:55:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/5272/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:67:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:68:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5272/gpio.c:69:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/5249/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5249/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/523x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:38:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/523x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
rch/m68knommu/platform/520x/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/520x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
...
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/5206e/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast CC kernel/panic.o
arch/m68knommu/platform/5206e/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206e/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Fix these compiler warnings:
arch/m68knommu/platform/5206/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
arch/m68knommu/platform/5206/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The intc-simr interrupt controller on some ColdFire CPUs has a set range of
interrupts its supports (64 through 128 or 192 depending on model). We
shouldn't be setting this handler for every possible interrupt from 0 to
255. Set more appropriate limits, and this means we can drop the interrupt
number check in the mask and unmask routines.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Use a proper irq_startup() routine to intialize the interrupt priority
and level register in the ColdFire intc-2 controller code. We shouldn't
be checking if the priority/level has been set on every unmask operation.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The intc-2 interrupt controller on some ColdFire CPUs has a set range of
interrupts its supports (64 through 128 or 192 depending on model). We
shouldn't be setting this handler for every possible interrupt from 0 to
255. Set more appropriate limits, and this means we can drop the interrupt
number check in the mask and unmask routines.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The FireBee is a ColdFire 5475 based board. Add a configuration option
to support it, and the basic platform flash layout code.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Most ColdFire CPUs have an internal peripheral set that can be mapped at
a user selectable address. Different ColdFire parts either use an MBAR
register of an IPSBAR register to map the peripheral region. Most boards
use the Freescale default mappings - but not all.
Make the setting of the MBAR or IPSBAR register configurable. And only make
the selection available on the appropriate ColdFire CPU types.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Different ColdFire CPUs have different ways of defining where their
internal peripheral registers sit in their address space. Some use an
MBAR register, some use and IPSBAR register, some have a fixed mapping.
Now that most of the peripheral address definitions have been cleaned up
we can clean up the setting of the MBAR and IPSBAR defines to limit them
to just where they are needed (and where they actually exist).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
In some of the RAM size autodetection code on ColdFire CPU startup
we reference DRAM registers relative to the MBAR register. Not all of
the supported ColdFire CPUs have an MBAR, and currently this works
because we fake an MBAR address on those registers. In an effort to
clean this up, and eventually remove the fake MBAR setting make the
DRAM register address definitions actually contain the MBAR (or IPSBAR
as appropriate) value as required.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Not all ColdFire CPUs that use the old style timer hardware module use
an MBAR set peripheral region. Move the TIMER base address defines to the
per-CPU header files where we can set it correctly based on how the
peripherals are mapped - instead of using a fake MBAR for some platforms.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The base addresses of the ColdFire DMA unit registers belong with
all the other address definitions in the per-cpu headers. The current
definitions assume they are relative to an MBAR register. Not all
ColdFire CPUs have an MBAR register. A clean address define can only
be acheived in the per-cpu headers along with all the other chips
peripheral base addresses.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 528x family of CPUs does not have an MBAR register, so don't
define its peripheral addresses relative to one. Its internal peripherals
are relative to the IPSBAR register, so make sure to use that.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 527x family of CPUs does not have an MBAR register, so don't
define its peripheral addresses relative to one. Its internal peripherals
are relative to the IPSBAR register, so make sure to use that.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 523x family of CPUs does not have an MBAR register, so don't
define its peripheral addresses relative to one. Its internal peripherals
are relative to the IPSBAR register, so make sure to use that.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 5207 and 5208 CPUs have fixed peripheral addresses.
They do not use the setable peripheral address registers like the MBAR
and IPSBAR used on many other ColdFire parts. Don't use fake values
of MBAR and IPSBAR when using peripheral addresses for them, there
is no need to.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The PIT hardware timer module used in some ColdFire CPU's is not always
addressed relative to an IPSBAR register. Parts like the ColdFire 5207 and
5208 have fixed peripheral addresses. So lets not define the register
addresses of the PIT relative to an IPSBAR definition. Move the base
address definitions into the per-part headers. This is a lot more consistent
since all the other peripheral base addresses are defined in the per-part
header files already.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Remove the bogus definition of the MBAR register for the ColdFire 532x
family. It doesn't have an MBAR register, its peripheral registers are
at fixed addresses and are not relative to a settable base.
All the code that relyed on this definition existing has been cleaned
up. The register address definitions now include the base as required.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 54xx family shares the same interrupt controller used
on the 523x, 527x and 528x ColdFire parts, but it isn't offset
relative to the IPSBAR register. The 54xx doesn't have an IPSBAR
register.
By including the base address of the peripheral registers in the register
definitions (MCFICM_INTC0 and MCFICM_INTC1 in this case) we can avoid
having to define a fake IPSBAR for the 54xx. And this makes the register
address definitions of these more consistent, the majority of the other
register address defines include the peripheral base address already.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The MBAR2 register is only used on the ColdFire 5249 part, so move its
definition out of the common coldfire.h and into the 5249 support header.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
/me idly wonders what sets the handlers for this chip.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
That handler lacks the minimal checks for action being zero etc. Keep
the weird flow - ack before handling - intact and call into
handle_simple_irq which does the right thing.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
LKML-Reference: <20110202212552.413849952@linutronix.de>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
