linux-toradex.git/include, branch v2.6.25.4

sparc: Fix debugger syscall restart interactions.

2008-05-15T14:50:06+00:00

[ This is a 2.6.25 backport of upstream changeset
  28e6103665301ce60634e8a77f0b657c6cc099de with sparc32 build
  fixes from Robert Reif ]

So, forever, we've had this ptrace_signal_deliver implementation
which tries to handle all of the nasties that can occur when the
debugger looks at a process about to take a signal.  It's meant
to address all of these issues inside of the kernel so that the
debugger need not be mindful of such things.

Problem is, this doesn't work.

The idea was that we should do the syscall restart business first, so
that the debugger captures that state.  Otherwise, if the debugger for
example saves the child's state, makes the child execute something
else, then restores the saved state, we won't handle the syscall
restart properly because we lose the "we're in a syscall" state.

The code here worked for most cases, but if the debugger actually
passes the signal through to the child unaltered, it's possible that
we would do a syscall restart when we shouldn't have.

In particular this breaks the case of debugging a process under a gdb
which is being debugged by yet another gdb.  gdb uses sigsuspend
to wait for SIGCHLD of the inferior, but if gdb itself is being
debugged by a top-level gdb we get a ptrace_stop().  The top-level gdb
does a PTRACE_CONT with SIGCHLD to let the inferior gdb see the
signal.  But ptrace_signal_deliver() assumed the debugger would cancel
out the signal and therefore did a syscall restart, because the return
error was ERESTARTNOHAND.

Fix this by simply making ptrace_signal_deliver() a nop, and providing
a way for the debugger to control system call restarting properly:

1) Report a "in syscall" software bit in regs->{tstate,psr}.
   It is set early on in trap entry to a system call and is fully
   visible to the debugger via ptrace() and regsets.

2) Test this bit right before doing a syscall restart.  We have
   to do a final recheck right after get_signal_to_deliver() in
   case the debugger cleared the bit during ptrace_stop().

3) Clear the bit in trap return so we don't accidently try to set
   that bit in the real register.

As a result we also get a ptrace_{is,clear}_syscall() for sparc32 just
like sparc64 has.

M68K has this same exact bug, and is now the only other user of the
ptrace_signal_deliver hook.  It needs to be fixed in the same exact
way as sparc.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Fix mremap address range validation.

2008-05-15T14:50:05+00:00

Just like mmap, we need to validate address ranges regardless
of MAP_FIXED.

sparc{,64}_mmap_check()'s flag argument is unused, remove.

Based upon a report and preliminary patch by
Jan Lieskovsky 

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Fix ptrace() detach.

2008-05-15T14:50:05+00:00

[ Upstream commit: 986bef854fab44012df678a5b51817d5274d3ca1 ]

Forever we had a PTRACE_SUNOS_DETACH which was unconditionally
recognized, regardless of the personality of the process.

Unfortunately, this value is what ended up in the GLIBC sys/ptrace.h
header file on sparc as PTRACE_DETACH and PT_DETACH.

So continue to recognize this old value.  Luckily, it doesn't conflict
with anything we actually care about.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system)

2008-05-15T14:50:05+00:00

commit 5c3a121d52b30a1e53cdaa802fa1965fcd243164 upstream

System topology on intel based system needs to be exported
for non-numa case as well.

All parts of asm-i386/topology.h has come under
#ifdef CONFIG_NUMA after the merge to asm-x86/topology.h

/sys/devices/system/cpu/cpu?/topology/* is populated based on
ENABLE_TOPO_DEFINES

The sysfs cpu topology is not being populated on my dual socket
dual core xeon 5160 processor based (x86 32 bit) system.

CONFIG_NUMA is not set in my case yet the topology is relevant
and useful.

irqbalance daemon application depends on topology to build the
cpus and package list and it fails on Fedora9 beta since the
sysfs topology was not being populated in the 2.6.25 kernel.

I am not sure if it was intentional to not define ENABLE_TOPO_DEFINES
for non-numa systems.

This fix has been tested on the above mentioned dual core, dual socket
system.

Signed-off-by: Vaidyanathan Srinivasan 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

nf_conntrack: padding breaks conntrack hash on ARM

2008-05-15T14:50:03+00:00

[NETFILTER]: nf_conntrack: padding breaks conntrack hash on ARM

Upstream commit 443a70d50:

commit 0794935e "[NETFILTER]: nf_conntrack: optimize hash_conntrack()"
results in ARM platforms hashing uninitialised padding.  This padding
doesn't exist on other architectures.

Fix this by replacing NF_CT_TUPLE_U_BLANK() with memset() to ensure
everything is initialised.  There were only 4 bytes that
NF_CT_TUPLE_U_BLANK() wasn't clearing anyway (or 12 bytes on ARM).

Signed-off-by: Philip Craig 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

ipvs: fix oops in backup for fwmark conn templates

2008-05-15T14:50:02+00:00

[ Upstream commit: 2ad17defd596ca7e8ba782d5fc6950ee0e99513c ]

	Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=10556
where conn templates with protocol=IPPROTO_IP can oops backup box.

        Result from ip_vs_proto_get() should be checked because
protocol value can be invalid or unsupported in backup. But
for valid message we should not fail for templates which use
IPPROTO_IP. Also, add checks to validate message limits and
connection state. Show state NONE for templates using IPPROTO_IP.

Fix tested and confirmed by L0op8ack 

Signed-off-by: Julian Anastasov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

CRYPTO: api: Fix scatterwalk_sg_chain

2008-05-10T04:40:51+00:00

[CRYPTO] api: Fix scatterwalk_sg_chain

[ Upstream commit: 8ec970d8561abb5645d4602433b772e268c96d05 ]

When I backed out of using the generic sg chaining (as it isn't currently
portable) and introduced scatterwalk_sg_chain/scatterwalk_sg_next I left
out the sg_is_last check in the latter.  This causes it to potentially
dereference beyond the end of the sg array.

As most uses of scatterwalk_sg_next are bound by an overall length, this
only affected the chaining code in authenc and eseqiv. Thanks to Patrick
McHardy for identifying this problem.

This patch also clears the "last" bit on the head of the chained list as
it's no longer last.  This also went missing in scatterwalk_sg_chain and
is present in sg_chain.

Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

reiserfs: Unpack tails on quota files

2008-05-10T04:40:46+00:00

commit d5dee5c395062a55236318ac4eec1f4ebb9de6db upstream

Quota files cannot have tails because quota_write and quota_read functions do
not support them. So far when quota files did have tail, we just refused to
turn quotas on it. Sadly this check has been wrong and so there are now plenty
installations where quota files don't have NOTAIL flag set and so now after
fixing the check, they suddently fail to turn quotas on. Since it's easy to
unpack the tail from kernel, do this from reiserfs_quota_on() which solves the
problem and is generally nicer to users anyway.

Signed-off-by: Jan Kara 
Reported-by: 
Cc: Jeff Mahoney 
Cc: Chris Mason 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

IPSEC: Fix catch-22 with algorithm IDs above 31

2008-05-01T21:44:33+00:00

[ Upstream commit: c5d18e984a313adf5a1a4ae69e0b1d93cf410229 ]

As it stands it's impossible to use any authentication algorithms
with an ID above 31 portably.  It just happens to work on x86 but
fails miserably on ppc64.

The reason is that we're using a bit mask to check the algorithm
ID but the mask is only 32 bits wide.

After looking at how this is used in the field, I have concluded
that in the long term we should phase out state matching by IDs
because this is made superfluous by the reqid feature.  For current
applications, the best solution IMHO is to allow all algorithms when
the bit masks are all ~0.

The following patch does exactly that.

This bug was identified by IBM when testing on the ppc64 platform
using the NULL authentication algorithm which has an ID of 251.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

RTNETLINK: Fix bogus ASSERT_RTNL warning

2008-05-01T21:44:32+00:00

[ Upstream commit: c9c1014b2bd014c7ec037bbb6f58818162fdb265 ]

ASSERT_RTNL uses mutex_trylock to test whether the rtnl_mutex is
held. This bogus warnings when running in atomic context, which
f.e. happens when adding secondary unicast addresses through
macvlan or vlan or when synchronizing multicast addresses from
wireless devices.

Mid-term we might want to consider moving all address updates
to process context since the locking seems overly complicated,
for now just fix the bogus warning by changing ASSERT_RTNL to
use mutex_is_locked().

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman