linux, branch v2.6.29.3

Linux 2.6.29.3

2009-05-08T22:47:21Z

ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

2009-05-08T22:45:12Z

This is a port of commit 91ed19f5f66a7fe544f0ec385e981f43491d1d5a for 2.6.29. Without this after scanning your device will set the association ID to something bogus and what is being reported is multicast/broadcast frame are not being received. For details see this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=498502 >From the original commit: So that a new created IBSS network doesn't break on the first scan. It seems to Sujith and me that this stupid code unnecessary, too. So remove it... Reported-by: David Woodhouse Tested-by: David Woodhouse Signed-off-by: Alina Friedrichsen Signed-off-by: John W. Linville Signed-off-by: Jouni Malinen Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman

tracing: x86, mmiotrace: fix range test

2009-05-08T22:45:12Z

commit 33015c85995716d03f6293346cf05a1908b0fb9a upstream. Matching on (addr == (p->addr + p->len)) causes problems when mappings are adjacent. [ Impact: fix mmiotrace confusion on adjacent iomaps ] Signed-off-by: Stuart Bennett Acked-by: Pekka Paalanen Cc: Steven Rostedt LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

sched: account system time properly

2009-05-08T22:45:12Z

commit f5f293a4e3d0a0c52cec31de6762c95050156516 upstream. Andrew Gallatin reported that IRQ and SOFTIRQ times were sometime not reported correctly on recent kernels, and even bisected to commit 457533a7d3402d1d91fbc125c8bd1bd16dcd3cd4 ([PATCH] fix scaled & unscaled cputime accounting) as the first bad commit. Further analysis pointed that commit 79741dd35713ff4f6fd0eafd59fa94e8a4ba922d ([PATCH] idle cputime accounting) was the real cause of the problem. account_process_tick() was not taking into account timer IRQ interrupting the idle task servicing a hard or soft irq. On mostly idle cpu, irqs were thus not accounted and top or mpstat could tell user/admin that cpu was 100 % idle, 0.00 % irq, 0.00 % softirq, while it was not. [ Impact: fix occasionally incorrect CPU statistics in top/mpstat ] Reported-by: Andrew Gallatin Re-reported-by: Andrew Morton Signed-off-by: Eric Dumazet Acked-by: Martin Schwidefsky Cc: rick.jones2@hp.com Cc: brice@myri.com Cc: Paul Mackerras Cc: Benjamin Herrenschmidt LKML-Reference: <49F84BC1.7080602@cosmosbay.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

rndis_wlan: fix initialization order for workqueue&workers

2009-05-08T22:45:11Z

commit e805e4d0b53506dff4255a2792483f094e7fcd2c upstream. rndis_wext_link_change() might be called from rndis_command() at initialization stage and priv->workqueue/priv->work have not been initialized yet. This causes invalid opcode at rndis_wext_bind on some brands of bcm4320. Fix by initializing workqueue/workers in rndis_wext_bind() before rndis_command is used. This bug has existed since 2.6.25, reported at: http://bugzilla.kernel.org/show_bug.cgi?id=12794 Signed-off-by: Jussi Kivilinna Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mm: fix Committed_AS underflow on large NR_CPUS environment

2009-05-08T22:45:11Z

commit 00a62ce91e554198ef28234c91c36f850f5a3bc9 upstream The Committed_AS field can underflow in certain situations: > # while true; do cat /proc/meminfo | grep _AS; sleep 1; done | uniq -c > 1 Committed_AS: 18446744073709323392 kB > 11 Committed_AS: 18446744073709455488 kB > 6 Committed_AS: 35136 kB > 5 Committed_AS: 18446744073709454400 kB > 7 Committed_AS: 35904 kB > 3 Committed_AS: 18446744073709453248 kB > 2 Committed_AS: 34752 kB > 9 Committed_AS: 18446744073709453248 kB > 8 Committed_AS: 34752 kB > 3 Committed_AS: 18446744073709320960 kB > 7 Committed_AS: 18446744073709454080 kB > 3 Committed_AS: 18446744073709320960 kB > 5 Committed_AS: 18446744073709454080 kB > 6 Committed_AS: 18446744073709320960 kB Because NR_CPUS can be greater than 1000 and meminfo_proc_show() does not check for underflow. But NR_CPUS proportional isn't good calculation. In general, possibility of lock contention is proportional to the number of online cpus, not theorical maximum cpus (NR_CPUS). The current kernel has generic percpu-counter stuff. using it is right way. it makes code simplify and percpu_counter_read_positive() don't make underflow issue. Reported-by: Dave Hansen Signed-off-by: KOSAKI Motohiro Cc: Eric B Munson Cc: Mel Gorman Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

Ignore madvise(MADV_WILLNEED) for hugetlbfs-backed regions

2009-05-08T22:45:11Z

commit a425a638c858fd10370b573bde81df3ba500e271 upstream. madvise(MADV_WILLNEED) forces page cache readahead on a range of memory backed by a file. The assumption is made that the page required is order-0 and "normal" page cache. On hugetlbfs, this assumption is not true and order-0 pages are allocated and inserted into the hugetlbfs page cache. This leaks hugetlbfs page reservations and can cause BUGs to trigger related to corrupted page tables. This patch causes MADV_WILLNEED to be ignored for hugetlbfs-backed regions. Signed-off-by: Mel Gorman Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

clockevents: prevent endless loop in tick_handle_periodic()

2009-05-08T22:45:10Z

commit 74a03b69d1b5ce00a568e142ca97e76b7f5239c6 upstream. tick_handle_periodic() can lock up hard when a one shot clock event device is used in combination with jiffies clocksource. Avoid an endless loop issue by requiring that a highres valid clocksource be installed before we call tick_periodic() in a loop when using ONESHOT mode. The result is we will only increment jiffies once per interrupt until a continuous hardware clocksource is available. Without this, we can run into a endless loop, where each cycle through the loop, jiffies is updated which increments time by tick_period or more (due to clock steering), which can cause the event programming to think the next event was before the newly incremented time and fail causing tick_periodic() to be called again and the whole process loops forever. [ Impact: prevent hard lock up ] Signed-off-by: John Stultz Signed-off-by: Andrew Morton Signed-off-by: Thomas Gleixner Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

intel-iommu: Avoid panic() for DRHD at address zero.

2009-05-08T22:45:10Z

(cherry picked from commit e523b38e2f568af58baa13120a994cbf24e6dee0) If the BIOS does something obviously stupid, like claiming that the registers for the IOMMU are at physical address zero, then print a nasty message and abort, rather than trying to set up the IOMMU and then later panicking. It's becoming more and more obvious that trusting this stuff to the BIOS was a mistake. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

intel-iommu: Fix oops in device_to_iommu() when devices not found.

2009-05-08T22:45:10Z

(cherry picked from commit 4958c5dc7bcb2e42d985cd26aeafd8a7eca9ab1e) It's possible for a device in the drhd->devices[] array to be NULL if it wasn't found at boot time, which means we have to check for that case. Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman