~thopiekar/linux/+git/linux-stable:linux-2.6.26.y

Last commit made on 2008-11-10
Get this branch:
git clone -b linux-2.6.26.y https://git.launchpad.net/~thopiekar/linux/+git/linux-stable

Branch merges

Branch information

Name:
linux-2.6.26.y
Repository:
lp:~thopiekar/linux/+git/linux-stable

Recent commits

63e0e67... by Greg Kroah-Hartman <email address hidden> on 2008-11-10

Linux 2.6.26.8

fda28f0... by Patrick McHardy <email address hidden> on 2008-10-22

netfilter: restore lost ifdef guarding defrag exception

netfilter: restore lost #ifdef guarding defrag exception

Upstream commit 38f7ac3eb:

Nir Tzachar <email address hidden> reported a warning when sending
fragments over loopback with NAT:

[ 6658.338121] WARNING: at net/ipv4/netfilter/nf_nat_standalone.c:89 nf_nat_fn+0x33/0x155()

The reason is that defragmentation is skipped for already tracked connections.
This is wrong in combination with NAT and ip_conntrack actually had some ifdefs
to avoid this behaviour when NAT is compiled in.

The entire "optimization" may seem a bit silly, for now simply restoring the
lost #ifdef is the easiest solution until we can come up with something better.

Signed-off-by: Patrick McHardy <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

27caba5... by Ilpo Järvinen <email address hidden> on 2008-10-22

netfilter: snmp nat leaks memory in case of failure

netfilter: snmp nat leaks memory in case of failure

Upstream commit 311670f3e:

Signed-off-by: Ilpo Jarvinen <email address hidden>
Signed-off-by: Patrick McHardy <email address hidden>

2eac944... by adobriyan on 2008-10-22

netfilter: xt_iprange: fix range inversion match

netfilter: xt_iprange: fix range inversion match

Upstream commit 6def1eb48:

Inverted IPv4 v1 and IPv6 v0 matches don't match anything since 2.6.25-rc1!

Signed-off-by: Alexey Dobriyan <email address hidden>
Acked-by: Jan Engelhardt <email address hidden>
Signed-off-by: Patrick McHardy <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

4bdaa73... by Shaohua Li on 2008-11-06

ACPI: dock: avoid check _STA method

commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db upstream.

ACPI: dock: avoid check _STA method

In some BIOSes, every _STA method call will send a notification again,
this cause freeze. And in some BIOSes, it appears _STA should be called
after _DCK. This tries to avoid calls _STA, and still keep the device
present check.

http://bugzilla.kernel.org/show_bug.cgi?id=10431

Signed-off-by: Shaohua Li <email address hidden>
Signed-off-by: Len Brown <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

a133c85... by Julia Jomantaite <email address hidden> on 2008-10-28

ACPI: video: fix brightness allocation

upstream commit 469778c1740fcf3113498b6fdf4559bdec25c58f

Thanks to Arjan for spotting this
http://www.kerneloops.org/search.php?search=acpi_video_switch_brightness
and suggesting it for .stable

Fix use of uninitialized device->brightness.

Signed-off-by: Julia Jomantaite <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>
Acked-by: Zhang Rui <email address hidden>
Signed-off-by: Len Brown <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

f0d6570... by Andrea Shepard <email address hidden> on 2008-10-20

sparc64: Fix race in arch/sparc64/kernel/trampoline.S

[ Upstream commit e0037df3852b4b60edbe01f70f4968e4a9fdb272 ]

Make arch/sparc64/kernel/trampoline.S in 2.6.27.1 lock prom_entry_lock
when calling the PROM. This prevents a race condition that I observed
causing a hang on startup on a 12-CPU E4500.

I am not subscribed to this list, so please CC me on replies.

Signed-off-by: Andrea Shepard <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

0cba8ac... by Kumar Gala <email address hidden> on 2008-10-22

math-emu: Fix signalling of underflow and inexact while packing result.

[ Upstream commit 930cc144a043ff95e56b6888fa51c618b33f89e7 ]

I'm trying to move the powerpc math-emu code to use the include/math-emu bits.

In doing so I've been using TestFloat to see how good or bad we are
doing. For the most part the current math-emu code that PPC uses has
a number of issues that the code in include/math-emu seems to solve
(plus bugs we've had for ever that no one every realized).

Anyways, I've come across a case that we are flagging underflow and
inexact because we think we have a denormalized result from a double
precision divide:

000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE
 soft: 001.0000000000000 ..... syst: 001.0000000000000 ...ux

What it looks like is the results out of FP_DIV_D are:

D:
sign: 0
mantissa: 01000000 00000000
exp: -1023 (0)

The problem seems like we aren't normalizing the result and bumping the exp.

Now that I'm digging into this a bit I'm thinking my issue has to do with
the fix DaveM put in place from back in Aug 2007 (commit
405849610fd96b4f34cd1875c4c033228fea6c0f):

[MATH-EMU]: Fix underflow exception reporting.

    2) we ended up rounding back up to normal (this is the case where
       we set the exponent to 1 and set the fraction to zero), this
       should set inexact too
...

    Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
    inexact and underflow. The cpu implementations and ieee1754
    literature is very clear about this. This is case #2 above.

Here is the distilled glibc test case from Jakub Jelinek which prompted that
commit:

--------------------
#include <float.h>
#include <fenv.h>
#include <stdio.h>

volatile double d = DBL_MIN;
volatile double e = 0x0.0000000000001p-1022;
volatile double f = 16.0;
int
main (void)
{
  printf ("%x\n", fetestexcept (FE_UNDERFLOW));
  d /= f;
  printf ("%x\n", fetestexcept (FE_UNDERFLOW));
  e /= f;
  printf ("%x\n", fetestexcept (FE_UNDERFLOW));
  return 0;
}
--------------------

It looks like the case I have we are exact before rounding, but think it
looks like the rounding case since it appears as if "overflow is set".

000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE = 001.0000000000000

I think the following adds the check for my case and still works for the
issue your commit was trying to resolve.

Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

657f714... by Ilpo Järvinen <email address hidden> on 2008-10-08

tcpv6: fix option space offsets with md5

[ Upstream commit 53b125779fb0b29e5b316bf3dc7d199e6dcea567 ]

More breakage :-), part of timestamps just were previously
overwritten.

Signed-off-by: Ilpo Järvinen <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

858fac9... by Herbert Xu on 2008-10-07

net: Fix netdev_run_todo dead-lock

[ Upstream commit 58ec3b4db9eb5a28e3aec5f407a54e28f7039c19 ]

Benjamin Thery tracked down a bug that explains many instances
of the error

unregister_netdevice: waiting for %s to become free. Usage count = %d

It turns out that netdev_run_todo can dead-lock with itself if
a second instance of it is run in a thread that will then free
a reference to the device waited on by the first instance.

The problem is really quite silly. We were trying to create
parallelism where none was required. As netdev_run_todo always
follows a RTNL section, and that todo tasks can only be added
with the RTNL held, by definition you should only need to wait
for the very ones that you've added and be done with it.

There is no need for a second mutex or spinlock.

This is exactly what the following patch does.

Signed-off-by: Herbert Xu <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>