linux-toradex.git, branch v2.6.25.14

Linux 2.6.25.14

2008-08-01T19:07:26+00:00

Fix off-by-one error in iov_iter_advance()

2008-08-01T18:51:02+00:00

commit 94ad374a0751f40d25e22e036c37f7263569d24c upstream

The iov_iter_advance() function would look at the iov->iov_len entry
even though it might have iterated over the whole array, and iov was
pointing past the end.  This would cause DEBUG_PAGEALLOC to trigger a
kernel page fault if the allocation was at the end of a page, and the
next page was unallocated.

The quick fix is to just change the order of the tests: check that there
is any iovec data left before we check the iov entry itself.

Thanks to Alexey Dobriyan for finding this case, and testing the fix.

Reported-and-tested-by: Alexey Dobriyan 
Cc: Nick Piggin 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

netfilter -stable: nf_conntrack_tcp: fix endless loop

2008-08-01T18:51:02+00:00

netfilter: nf_conntrack_tcp: fix endless loop

Upstream commit 6b69fe0:

When a conntrack entry is destroyed in process context and destruction
is interrupted by packet processing and the packet is an attempt to
reopen a closed connection, TCP conntrack tries to kill the old entry
itself and returns NF_REPEAT to pass the packet through the hook
again. This may lead to an endless loop: TCP conntrack repeatedly
finds the old entry, but can not kill it itself since destruction
is already in progress, but destruction in process context can not
complete since TCP conntrack is keeping the CPU busy.

Drop the packet in TCP conntrack if we can't kill the connection
ourselves to avoid this.

Reported by: hemao77@gmail.com [ Kernel bugzilla #11058 ]
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Correct hash flushing from huge_ptep_set_wrprotect()

2008-08-01T18:51:01+00:00

Correct hash flushing from huge_ptep_set_wrprotect() [stable tree version]

A fix for incorrect flushing of the hash page table at fork() for
hugepages was recently committed as
86df86424939d316b1f6cfac1b6204f0c7dee317.  Without this fix, a process
can make a MAP_PRIVATE hugepage mapping, then fork() and have writes
to the mapping after the fork() pollute the child's version.

Unfortunately this bug also exists in the stable branch.  In fact in
that case copy_hugetlb_page_range() from mm/hugetlb.c calls
ptep_set_wrprotect() directly, the hugepage variant hook
huge_ptep_set_wrprotect() doesn't even exist.

The patch below is a port of the fix to the stable25/master branch.
It introduces a huge_ptep_set_wrprotect() call, but this is #defined
to be equal to ptep_set_wrprotect() unless the arch defines its own
version and sets __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT.

This arch preprocessor flag is kind of nasty, but it seems the sanest
way to introduce this fix with minimum risk of breaking other archs
for whom prep_set_wprotect() is suitable for hugepages.

Signed-off-by: Andy Whitcroft 
Signed-off-by: David Gibson 
Signed-off-by: Greg Kroah-Hartman

ath5k: don't enable MSI, we cannot handle it yet

2008-08-01T18:51:00+00:00

commit 256b152b005e319f985f50f2a910a75ba0def74f upstream

MSI is a nice thing, but we cannot enable it without changing the
interrupt handler.  If we do it, we break MSI capable hardware,
specifically AR5006 chipset.

Signed-off-by: Pavel Roskin 
Acked-by: Nick Kossifidis 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43legacy: Release mutex in error handling code

2008-08-01T18:50:59+00:00

commit 4104863fb4a724723d1d5f3cba9d3c5084087e45 upstream

The mutex is released on a successful return, so it would seem that it
should be released on an error return as well.

The semantic patch finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// 
@@
expression l;
@@

mutex_lock(l);
.. when != mutex_unlock(l)
    when any
    when strict
(
if (...) { ... when != mutex_unlock(l)
+   mutex_unlock(l);
    return ...;
}
|
mutex_unlock(l);
)
// 

Signed-off-by: Julia Lawall 
Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-08-01T18:50:58+00:00

commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger 
Cc: Andi Kleen 
Cc: Len Brown 
Cc: Dave Jones 
Cc: Ingo Molnar 
Cc: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: use page_alloc not kmalloc to get a page of memory

2008-08-01T18:50:57+00:00

commit 7fcba054373d5dfc43d26e243a5c9b92069972ee upstream
Date: Mon, 28 Jul 2008 15:46:39 -0700
Subject: eCryptfs: use page_alloc not kmalloc to get a page of memory

With SLUB debugging turned on in 2.6.26, I was getting memory corruption
when testing eCryptfs.  The root cause turned out to be that eCryptfs was
doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice
page-aligned chunk of memory.  But at least with SLUB debugging on, this
is not always true, and the page we get from virt_to_page does not
necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc.

My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2
different multi-megabyte files.  With this change I no longer see the
corruption.

Signed-off-by: Eric Sandeen 
Acked-by: Michael Halcrow 
Acked-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ixgbe: remove device ID for unsupported device

2008-08-01T18:50:56+00:00

commit bb5d10ac8cc315d53306963001fe650d88a1cbb2 upstream

The ixgbe driver was untested with device ID 8086:10c8 but still advertises
support.  Currently if this device is present in the system when the driver
is loaded, the system will panic.
Remove this device ID until full support can be tested with available
hardware.  This patch is necessary for 2.6.24, 2.6.25 and 2.6.26

Signed-off-by: Jesse Brandeburg 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

markers: fix markers read barrier for multiple probes

2008-08-01T18:50:55+00:00

commit 5def9a3a22e09c99717f41ab7f07ec9e1a1f3ec8 upstream

Paul pointed out two incorrect read barriers in the marker handler code in
the path where multiple probes are connected.  Those are ordering reads of
"ptype" (single or multi probe marker), "multi" array pointer, and "multi"
array data access.

It should be ordered like this :

read ptype
smp_rmb()
read multi array pointer
smp_read_barrier_depends()
access data referenced by multi array pointer

The code with a single probe connected (optimized case, does not have to
allocate an array) has correct memory ordering.

It applies to kernel 2.6.26.x, 2.6.25.x and linux-next.

Signed-off-by: Mathieu Desnoyers 
Cc: Paul E. McKenney 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman