linux, branch v2.6.26.4

Linux 2.6.26.4

2008-09-08T11:44:46Z

sata_mv: don't issue two DMA commands concurrently

2008-09-08T11:44:32Z

commit 4bdee6c5103696a2729d3db2f235d202191788e4 upstream sata_mv allowed issuing two DMA commands concurrently which the hardware allows. Unfortunately, libata core layer isn't ready for this yet and spews ugly warning message and malfunctions on this. Don't allow concurrent DMA commands for now. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Cc: Martin Michlmayr Cc: Mark Lord Cc: Artem Bokhan Signed-off-by: Greg Kroah-Hartman

KVM: MMU: Fix torn shadow pte

2008-09-08T11:44:32Z

(cherry picked from commit cd5998ebfbc9e6cb44408efa217c15d7eea13675) The shadow code assigns a pte directly in one place, which is nonatomic on i386 can can cause random memory references. Fix by using an atomic setter. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

x86: work around MTRR mask setting, v2

2008-09-08T11:44:32Z

commit 9754a5b840a209bc1f192d59f63e81b698a55ac8 upstream x86: work around MTRR mask setting, v2 improve the debug printout: - make it actually display something - print it only once would be nice to have a WARN_ONCE() facility, to feed such things to kerneloops.org. Signed-off-by: Ingo Molnar Cc: Yinghai Lu Signed-off-by: Greg Kroah-Hartman

nfsd: fix buffer overrun decoding NFSv4 acl

2008-09-08T11:44:32Z

commit 91b80969ba466ba4b915a4a1d03add8c297add3f upstream The array we kmalloc() here is not large enough. Thanks to Johann Dahm and David Richter for bug report and testing. Signed-off-by: J. Bruce Fields Cc: David Richter Tested-by: Johann Dahm Signed-off-by: Greg Kroah-Hartman

sunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports

2008-09-08T11:44:30Z

commit 27df6f25ff218072e0e879a96beeb398a79cdbc8 upstream Vegard Nossum reported ---------------------- > I noticed that something weird is going on with /proc/sys/sunrpc/transports. > This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When > I "cat" this file, I get the expected output: > $ cat /proc/sys/sunrpc/transports > tcp 1048576 > udp 32768 > But I think that it does not check the length of the buffer supplied by > userspace to read(). With my original program, I found that the stack was > being overwritten by the characters above, even when the length given to > read() was just 1. David Wagner added (among other things) that copy_to_user could be probably used here. Ingo Oeser suggested to use simple_read_from_buffer() here. The conclusion is that proc_do_xprt doesn't check for userside buffer size indeed so fix this by using Ingo's suggestion. Reported-by: Vegard Nossum Signed-off-by: Cyrill Gorcunov CC: Ingo Oeser Cc: Neil Brown Cc: Chuck Lever Cc: Greg Banks Cc: Tom Tucker Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

r8169: balance pci_map / pci_unmap pair

2008-09-08T11:44:30Z

commit a866bbf6aacf95f849810079442a20be118ce905 upstream The leak hurts with swiotlb and jumbo frames. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468. Heavily hinted by Ilpo Järvinen . Signed-off-by: Francois Romieu Tested-by: Alistair John Strachan Tested-by: Timothy J Fontaine Cc: Edward Hsu Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

tg3: Fix firmware event timeouts

2008-09-08T11:44:30Z

patch 4ba526ced990f4d61ee8d65fe8a6f0745e8e455c upstream The git commit 7c5026aa9b81dd45df8d3f4e0be73e485976a8b6 ("tg3: Add link state reporting to UMP firmware") introduced code that waits for previous firmware events to be serviced before attempting to submit a new event. Unfortunately that patch contained a bug that cause the driver to wait 2.5 seconds, rather than 2.5 milliseconds as intended. This patch fixes that bug. This bug revealed that not all firmware versions service driver events though. Since we do not know which versions of the firmware do and don't service these events, the driver needs some way to minimize the effects of the delay. This patch solves the problem by recording a jiffies timestamp when it submits an event to the hardware. If the jiffies counter shows that 2.5 milliseconds have already passed, a wait is not needed and the driver can proceed to submit a new event. Signed-off-by: Matt Carlson Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

crypto: authenc - Avoid using clobbered request pointer

2008-09-08T11:44:29Z

crypto: authenc - Avoid using clobbered request pointer [ Upstream commit: a697690bece75d4ba424c1318eb25c37d41d5829 ] Authenc works in two stages for encryption, it first encrypts and then computes an ICV. The context memory of the request is used by both operations. The problem is that when an asynchronous encryption completes, we will compute the ICV and then reread the context memory of the encryption to get the original request. It just happens that we have a buffer of 16 bytes in front of the request pointer, so ICVs of 16 bytes (such as SHA1) do not trigger the bug. However, any attempt to uses a larger ICV instantly kills the machine when the first asynchronous encryption is completed. This patch fixes this by saving the request pointer before we start the ICV computation. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

sparc64: Fix cmdline_memory_size handling bugs.

2008-09-08T11:44:29Z

[ Upstream commit f2b6079464fc73cf12f08248180a618f05033a70 ] First, lmb_enforce_memory_limit() interprets it's argument (mostly, heh) as a size limit not an address limit. So pass the raw cmdline_memory_size value into it. And we don't need to check it against zero, lmb_enforce_memory_limit() does that for us. Next, free_initmem() needs special handling when the kernel command line trims the available memory. The problem case is if the trimmed out memory is where the kernel image itself resides. When that memory is trimmed out, we don't add those physical ram areas to the sparsemem active ranges, amongst other things. Which means that this free_initmem() code will free up invalid page structs, resulting in either crashes or hangs. Just quick fix this by not freeing initmem at all if "mem=" was given on the boot command line. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman