user/sven/linux.git, branch v2.6.29.1

Linux 2.6.29.1

2009-04-02T20:55:27Z

V4L: v4l2-common: remove incorrect MODULE test

2009-04-02T20:55:20Z

upstream commit: d64260d58865004c6354e024da3450fdd607ea07 v4l2-common doesn't have to be a module for it to call request_module(). Just remove that test. Without this patch loading ivtv as a module while v4l2-common is compiled into the kernel will cause a delayed load of the i2c modules that ivtv needs since request_module is never called directly. While it is nice to see the delayed load in action, it is not so nice in that ivtv fails to do a lot of necessary i2c initializations and will oops later on with a division-by-zero. Thanks to Mark Lord for reporting this and helping me figure out what was wrong. Thanks-to: Guennadi Liakhovetski Thanks-to: Mark Lord Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Michael Krufky Signed-off-by: Chris Wright

sparc64: Fix reset hangs on Niagara systems.

2009-04-02T20:55:20Z

[ Upstream commit ffaba674090f287afe0c44fd8d978c64c03581a8 ] Hypervisor versions older than version 1.6.1 cannot handle leaving the profile counter overflow interrupt chirping when the system does a soft reset. So use a reboot notifier to shut off the NMI watchdog. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

sparc64: Flush TLB before releasing pages.

2009-04-02T20:55:20Z

[ Upstream commit a552a42cfa91ab653128dff89a70c8dde7fed042 ] tlb_flush_mmu() needs to flush pending TLB entries before processing the mmu_gather ->pages list. Noticed by Benjamin Herrenschmidt. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

sparc64: Fix MM refcount check in smp_flush_tlb_pending().

2009-04-02T20:55:19Z

[ Upstream commit f9384d41c02408dd404aa64d66d0ef38adcf6479 ] As explained by Benjamin Herrenschmidt: > CPU 0 is running the context, task->mm == task->active_mm == your > context. The CPU is in userspace happily churning things. > > CPU 1 used to run it, not anymore, it's now running fancyfsd which > is a kernel thread, but current->active_mm still points to that > same context. > > Because there's only one "real" user, mm_users is 1 (but mm_count is > elevated, it's just that the presence on CPU 1 as active_mm has no > effect on mm_count(). > > At this point, fancyfsd decides to invalidate a mapping currently mapped > by that context, for example because a networked file has changed > remotely or something like that, using unmap_mapping_ranges(). > > So CPU 1 goes into the zapping code, which eventually ends up calling > flush_tlb_pending(). Your test will succeed, as current->active_mm is > indeed the target mm for the flush, and mm_users is indeed 1. So you > will -not- send an IPI to the other CPU, and CPU 0 will continue happily > accessing the pages that should have been unmapped. To fix this problem, check ->mm instead of ->active_mm, and this means: > So if you test current->mm, you effectively account for mm_users == 1, > so the only way the mm can be active on another processor is as a lazy > mm for a kernel thread. So your test should work properly as long > as you don't have a HW that will do speculative TLB reloads into the > TLB on that other CPU (and even if you do, you flush-on-switch-in should > get rid of any crap here). And therefore we should be OK. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

KVM: MMU: Fix another largepage memory leak

2009-04-02T20:55:19Z

upstream commit: c5bc22424021cabda862727fb3f5098b866f074d In the paging_fetch function rmap_remove is called after setting a large pte to non-present. This causes rmap_remove to not drop the reference to the large page. The result is a memory leak of that page. Cc: stable@kernel.org Signed-off-by: Joerg Roedel Acked-by: Marcelo Tosatti Signed-off-by: Avi Kivity [chrisw: backport to 2.6.29] Signed-off-by: Chris Wright

cfg80211: fix incorrect assumption on last_request for 11d

2009-04-02T20:55:19Z

upstream commit: cc0b6fe88e99096868bdbacbf486c97299533b5a The incorrect assumption is the last regulatory request (last_request) is always a country IE when processing country IEs. Although this is true 99% of the time the first time this happens this could not be true. This fixes an oops in the branch check for the last_request when accessing drv_last_ie. The access was done under the assumption the struct won't be null. Note to stable: to port to 29 replace as follows, only 29 has country IE code: s|NL80211_REGDOM_SET_BY_COUNTRY_IE|REGDOM_SET_BY_COUNTRY_IE Cc: stable@kernel.org Reported-by: Quentin Armitage Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville [chrisw: backport to 2.6.29] Signed-off-by: Chris Wright

lguest: fix spurious BUG_ON() on invalid guest stack.

2009-04-02T20:55:19Z

upstream commit: 6afbdd059c27330eccbd85943354f94c2b83a7fe Impact: fix crash on misbehaving guest gpte_addr() contains a BUG_ON(), insisting that the present flag is set. We need to return before we call it if that isn't the case. Signed-off-by: Rusty Russell Cc: stable@kernel.org Signed-off-by: Chris Wright

lguest: wire up pte_update/pte_update_defer

2009-04-02T20:55:19Z

upstream commit: b7ff99ea53cd16de8f6166c0e98f19a7c6ca67ee Impact: intermittent guest segv/crash fix I've been seeing random guest bad address crashes and segmentation faults: bisect led to 4f98a2fee8 (vmscan: split LRU lists into anon & file sets), but that's a red herring. It turns out that lguest never hooked up the pte_update/pte_update_defer calls, so our ptes were not always in sync. After the vmscan commit, the bug became reproducible; now a fsck in a 64MB guest causes reproducible pagetable corruption. Signed-off-by: Rusty Russell Cc: jeremy@xensource.com Cc: virtualization@lists.osdl.org Cc: stable@kernel.org Signed-off-by: Chris Wright

VM, x86, PAT: Change is_linear_pfn_mapping to not use vm_pgoff

2009-04-02T20:55:19Z

upstream commit: 4bb9c5c02153dfc89a6c73a6f32091413805ad7d Impact: fix false positive PAT warnings - also fix VirtalBox hang Use of vma->vm_pgoff to identify the pfnmaps that are fully mapped at mmap time is broken. vm_pgoff is set by generic mmap code even for cases where drivers are setting up the mappings at the fault time. The problem was originally reported here: http://marc.info/?l=linux-kernel&m=123383810628583&w=2 Change is_linear_pfn_mapping logic to overload VM_INSERTPAGE flag along with VM_PFNMAP to mean full PFNMAP setup at mmap time. Problem also tracked at: http://bugzilla.kernel.org/show_bug.cgi?id=12800 Reported-by: Thomas Hellstrom Tested-by: Frans Pop Signed-off-by: Venkatesh Pallipadi Signed-off-by: Suresh Siddha Cc: Nick Piggin Cc: "ebiederm@xmission.com" Cc: # only for 2.6.29.1, not .28 LKML-Reference: <20090313004527.GA7176@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Chris Wright