commit a5a9e7c9c19b03b471d3ec148698e90a1958bfcb Author: Greg Kroah-Hartman Date: Thu Apr 25 21:20:25 2013 -0700 Linux 3.4.42 commit 8fdeb71b5022b4578e3339b861019c5a00c77700 Author: Josef Bacik Date: Fri Apr 5 20:50:09 2013 +0000 Btrfs: make sure nbytes are right after log replay commit 4bc4bee4595662d8bff92180d5c32e3313a704b0 upstream. While trying to track down a tree log replay bug I noticed that fsck was always complaining about nbytes not being right for our fsynced file. That is because the new fsync stuff doesn't wait for ordered extents to complete, so the inodes nbytes are not necessarily updated properly when we log it. So to fix this we need to set nbytes to whatever it is on the inode that is on disk, so when we replay the extents we can just add the bytes that are being added as we replay the extent. This makes it work for the case that we have the wrong nbytes or the case that we logged everything and nbytes is actually correct. With this I'm no longer getting nbytes errors out of btrfsck. Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Lingzhu Xiang Reviewed-by: CAI Qian Signed-off-by: Greg Kroah-Hartman commit b00919cd72ed9753390a9fbb5541cbba12e5e826 Author: Linus Torvalds Date: Fri Apr 19 09:53:07 2013 -0700 vm: convert mtdchar mmap to vm_iomap_memory() helper commit 8558e4a26b00225efeb085725bc319f91201b239 upstream. This is my example conversion of a few existing mmap users. The mtdchar case is actually disabled right now (and stays disabled), but I did it because it showed up on my "git grep", and I was familiar with the code due to fixing an overflow problem in the code in commit 9c603e53d380 ("mtdchar: fix offset overflow detection"). Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5de41ebef9458aa13955c5a3792c2f86d6e4fdda Author: Linus Torvalds Date: Fri Apr 19 09:46:39 2013 -0700 vm: convert HPET mmap to vm_iomap_memory() helper commit 2323036dfec8ce3ce6e1c86a49a31b039f3300d1 upstream. This is my example conversion of a few existing mmap users. The HPET case is simple, widely available, and easy to test (Clemens Ladisch sent a trivial test-program for it). Test-program-by: Clemens Ladisch Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b67bca9e17d63641aceefe5d5b112c065b478206 Author: Linus Torvalds Date: Fri Apr 19 09:57:35 2013 -0700 vm: convert fb_mmap to vm_iomap_memory() helper commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream. This is my example conversion of a few existing mmap users. The fb_mmap() case is a good example because it is a bit more complicated than some: fb_mmap() mmaps one of two different memory areas depending on the page offset of the mmap (but happily there is never any mixing of the two, so the helper function still works). Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ada37d85783ec8e314bd9b020b89d8a63a7587f2 Author: Linus Torvalds Date: Fri Apr 19 10:01:04 2013 -0700 vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper commit 0fe09a45c4848b5b5607b968d959fdc1821c161d upstream. This is my example conversion of a few existing mmap users. The pcm mmap case is one of the more straightforward ones. Acked-by: Takashi Iwai Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c420060e7b21368c21972e8a29e4ff56abb9d219 Author: Linus Torvalds Date: Tue Apr 16 13:45:37 2013 -0700 vm: add vm_iomap_memory() helper function commit b4cbb197c7e7a68dbad0d491242e3ca67420c13e upstream. Various drivers end up replicating the code to mmap() their memory buffers into user space, and our core memory remapping function may be very flexible but it is unnecessarily complicated for the common cases to use. Our internal VM uses pfn's ("page frame numbers") which simplifies things for the VM, and allows us to pass physical addresses around in a denser and more efficient format than passing a "phys_addr_t" around, and having to shift it up and down by the page size. But it just means that drivers end up doing that shifting instead at the interface level. It also means that drivers end up mucking around with internal VM things like the vma details (vm_pgoff, vm_start/end) way more than they really need to. So this just exports a function to map a certain physical memory range into user space (using a phys_addr_t based interface that is much more natural for a driver) and hides all the complexity from the driver. Some drivers will still end up tweaking the vm_page_prot details for things like prefetching or cacheability etc, but that's actually relevant to the driver, rather than caring about what the page offset of the mapping is into the particular IO memory region. Acked-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds commit 726cc91ed26521f3e678346e5745203a70edd456 Author: Dave Airlie Date: Fri Jan 25 11:38:56 2013 +1000 fbcon: fix locking harder commit 054430e773c9a1e26f38e30156eff02dedfffc17 upstream. Okay so Alan's patch handled the case where there was no registered fbcon, however the other path entered in set_con2fb_map pit. In there we called fbcon_takeover, but we also took the console lock in a couple of places. So push the console lock out to the callers of set_con2fb_map, this means fbmem and switcheroo needed to take the lock around the fb notifier entry points that lead to this. This should fix the efifb regression seen by Maarten. Tested-by: Maarten Lankhorst Tested-by: Lu Hua Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6b48c21afcf0f9f01bb37144a5da3274a3590404 Author: Stephane Eranian Date: Tue Apr 16 13:51:43 2013 +0200 perf/x86: Fix offcore_rsp valid mask for SNB/IVB commit f1923820c447e986a9da0fc6bf60c1dccdf0408e upstream. The valid mask for both offcore_response_0 and offcore_response_1 was wrong for SNB/SNB-EP, IVB/IVB-EP. It was possible to write to reserved bit and cause a GP fault crashing the kernel. This patch fixes the problem by correctly marking the reserved bits in the valid mask for all the processors mentioned above. A distinction between desktop and server parts is introduced because bits 24-30 are only available on the server parts. This version of the patch is just a rebase to perf/urgent tree and should apply to older kernels as well. Signed-off-by: Stephane Eranian Cc: peterz@infradead.org Cc: jolsa@redhat.com Cc: ak@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit da307d100cd4979e353e8265d0691263aa2a0086 Author: Tommi Rantala Date: Sat Apr 13 22:49:14 2013 +0300 perf: Treat attr.config as u64 in perf_swevent_init() commit 8176cced706b5e5d15887584150764894e94e02f upstream. Trinity discovered that we fail to check all 64 bits of attr.config passed by user space, resulting to out-of-bounds access of the perf_swevent_enabled array in sw_perf_event_destroy(). Introduced in commit b0a873ebb ("perf: Register PMU implementations"). Signed-off-by: Tommi Rantala Cc: Peter Zijlstra Cc: davej@redhat.com Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Link: http://lkml.kernel.org/r/1365882554-30259-1-git-send-email-tt.rantala@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a3c21277df060c3c83b2aba4120d0370cf204d36 Author: Mathias Krause Date: Sun Apr 7 14:05:39 2013 +0200 crypto: algif - suppress sending source address information in recvmsg commit 72a763d805a48ac8c0bf48fdb510e84c12de51fe upstream. The current code does not set the msg_namelen member to 0 and therefore makes net/socket.c leak the local sockaddr_storage variable to userland -- 128 bytes of kernel stack memory. Fix that. Signed-off-by: Mathias Krause Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d6b8c333ca71eba35911fc4460ca37568ccfa9c0 Author: Rafał Miłecki Date: Tue Apr 2 15:57:26 2013 +0200 ssb: implement spurious tone avoidance commit 46fc4c909339f5a84d1679045297d9d2fb596987 upstream. And make use of it in b43. This fixes a regression introduced with 49d55cef5b1925a5c1efb6aaddaa40fc7c693335 b43: N-PHY: implement spurious tone avoidance This commit made BCM4322 use only MCS 0 on channel 13, which of course resulted in performance drop (down to 0.7Mb/s). Reported-by: Stefan Brüns Signed-off-by: Rafał Miłecki Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f4ec6e0f475dd23157042a150c8f3dcfa528a8ca Author: Felix Fietkau Date: Wed Apr 10 15:26:06 2013 +0200 ath9k_hw: change AR9580 initvals to fix a stability issue commit f09a878511997c25a76bf111a32f6b8345a701a5 upstream. The hardware parsing of Control Wrapper Frames needs to be disabled, as it has been causing spurious decryption error reports. The initvals for other chips have been updated to disable it, but AR9580 was left out for some reason. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 563868a2e90aa94d8af2dbdb2e448ed03b4847e5 Author: Felix Fietkau Date: Sun Apr 7 21:10:48 2013 +0200 ath9k_htc: accept 1.x firmware newer than 1.3 commit 319e7bd96aca64a478f3aad40711c928405b8b77 upstream. Since the firmware has been open sourced, the minor version has been bumped to 1.4 and the API/ABI will stay compatible across further 1.x releases. Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit bb93ad5d30517e917aec4062c97c7712c4acaa0f Author: Will Deacon Date: Fri Apr 12 19:04:19 2013 +0100 ARM: 7698/1: perf: fix group validation when using enable_on_exec commit cb2d8b342aa084d1f3ac29966245dec9163677fb upstream. Events may be created with attr->disabled == 1 and attr->enable_on_exec == 1, which confuses the group validation code because events with the PERF_EVENT_STATE_OFF are not considered candidates for scheduling, which may lead to failure at group scheduling time. This patch fixes the validation check for ARM, so that events in the OFF state are still considered when enable_on_exec is true. Reported-by: Sudeep KarkadaNagesha Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 9c275826b7522820c0346250bc373e32dfbec13d Author: Illia Ragozin Date: Wed Apr 10 19:43:34 2013 +0100 ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon commit cd272d1ea71583170e95dde02c76166c7f9017e6 upstream. On Feroceon the L2 cache becomes non-coherent with the CPU when the L1 caches are disabled. Thus the L2 needs to be invalidated after both L1 caches are disabled. On kexec before the starting the code for relocation the kernel, the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon), but after L2 cache is never invalidated, because inv_all is not set in cache-feroceon-l2.c. So kernel relocation and decompression may has (and usually has) errors. Setting the function enables L2 invalidation and fixes the issue. Signed-off-by: Illia Ragozin Acked-by: Jason Cooper Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 410537558144cc886d780a02af9a09a122bff35b Author: Tejun Heo Date: Mon Mar 18 12:22:34 2013 -0700 sched: Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s commit 383efcd00053ec40023010ce5034bd702e7ab373 upstream. try_to_wake_up_local() should only be invoked to wake up another task in the same runqueue and BUG_ON()s are used to enforce the rule. Missing try_to_wake_up_local() can stall workqueue execution but such stalls are likely to be finite either by another work item being queued or the one blocked getting unblocked. There's no reason to trigger BUG while holding rq lock crashing the whole system. Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s. Signed-off-by: Tejun Heo Acked-by: Steven Rostedt Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20130318192234.GD3042@htj.dyndns.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2a6b0247eee46f424e032fb7431cc4700ad19ea5 Author: Andrew Honig Date: Fri Mar 29 09:35:21 2013 -0700 KVM: Allow cross page reads and writes from cached translations. commit 8f964525a121f2ff2df948dac908dcc65be21b5b upstream. This patch adds support for kvm_gfn_to_hva_cache_init functions for reads and writes that will cross a page. If the range falls within the same memslot, then this will be a fast operation. If the range is split between two memslots, then the slower kvm_read_guest and kvm_write_guest are used. Tested: Test against kvm_clock unit tests. Signed-off-by: Andrew Honig Signed-off-by: Gleb Natapov Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit f56d137aa68f8edadac247aa48b335f2776954ff Author: Andy Honig Date: Wed Feb 20 14:49:16 2013 -0800 KVM: Fix bounds checking in ioapic indirect register reads (CVE-2013-1798) commit a2c118bfab8bc6b8bb213abfc35201e441693d55 upstream. If the guest specifies a IOAPIC_REG_SELECT with an invalid value and follows that with a read of the IOAPIC_REG_WINDOW KVM does not properly validate that request. ioapic_read_indirect contains an ASSERT(redir_index < IOAPIC_NUM_PINS), but the ASSERT has no effect in non-debug builds. In recent kernels this allows a guest to cause a kernel oops by reading invalid memory. In older kernels (pre-3.3) this allows a guest to read from large ranges of host memory. Tested: tested against apic unit tests. Signed-off-by: Andrew Honig Signed-off-by: Marcelo Tosatti Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit f6dfc740c1d8f6133d2f53c1074770c13d040364 Author: Andy Honig Date: Wed Feb 20 14:48:10 2013 -0800 KVM: x86: Convert MSR_KVM_SYSTEM_TIME to use gfn_to_hva_cache functions (CVE-2013-1797) commit 0b79459b482e85cb7426aa7da683a9f2c97aeae1 upstream. There is a potential use after free issue with the handling of MSR_KVM_SYSTEM_TIME. If the guest specifies a GPA in a movable or removable memory such as frame buffers then KVM might continue to write to that address even after it's removed via KVM_SET_USER_MEMORY_REGION. KVM pins the page in memory so it's unlikely to cause an issue, but if the user space component re-purposes the memory previously used for the guest, then the guest will be able to corrupt that memory. Tested: Tested against kvmclock unit test Signed-off-by: Andrew Honig Signed-off-by: Marcelo Tosatti Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit ce7d8662581f032101ca70bbe1a2e62cd93fd1bc Author: Andy Honig Date: Mon Mar 11 09:34:52 2013 -0700 KVM: x86: fix for buffer overflow in handling of MSR_KVM_SYSTEM_TIME (CVE-2013-1796) commit c300aa64ddf57d9c5d9c898a64b36877345dd4a9 upstream. If the guest sets the GPA of the time_page so that the request to update the time straddles a page then KVM will write onto an incorrect page. The write is done byusing kmap atomic to get a pointer to the page for the time structure and then performing a memcpy to that page starting at an offset that the guest controls. Well behaved guests always provide a 32-byte aligned address, however a malicious guest could use this to corrupt host kernel memory. Tested: Tested against kvmclock unit test. Signed-off-by: Andrew Honig Signed-off-by: Marcelo Tosatti Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit e3aa8553976945b33cc83c6432fab7568ba11b04 Author: Vyacheslav Dubeyko Date: Wed Apr 17 15:58:33 2013 -0700 hfsplus: fix potential overflow in hfsplus_file_truncate() commit 12f267a20aecf8b84a2a9069b9011f1661c779b4 upstream. Change a u32 to loff_t hfsplus_file_truncate(). Signed-off-by: Vyacheslav Dubeyko Cc: Christoph Hellwig Cc: Al Viro Cc: Hin-Tak Leung Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cf276742f2dcdf5258aac98447e8b4b9fba55aaa Author: Emese Revfy Date: Wed Apr 17 15:58:36 2013 -0700 kernel/signal.c: stop info leak via the tkill and the tgkill syscalls commit b9e146d8eb3b9ecae5086d373b50fa0c1f3e7f0f upstream. This fixes a kernel memory contents leak via the tkill and tgkill syscalls for compat processes. This is visible in the siginfo_t->_sifields._rt.si_sigval.sival_ptr field when handling signals delivered from tkill. The place of the infoleak: int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from) { ... put_user_ex(ptr_to_compat(from->si_ptr), &to->si_ptr); ... } Signed-off-by: Emese Revfy Reviewed-by: PaX Team Signed-off-by: Kees Cook Cc: Al Viro Cc: Oleg Nesterov Cc: "Eric W. Biederman" Cc: Serge Hallyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f42097f7eb860a967d1629c4bb00f2a083edc1dc Author: Naoya Horiguchi Date: Wed Apr 17 15:58:30 2013 -0700 hugetlbfs: add swap entry check in follow_hugetlb_page() commit 9cc3a5bd40067b9a0fbd49199d0780463fc2140f upstream. With applying the previous patch "hugetlbfs: stop setting VM_DONTDUMP in initializing vma(VM_HUGETLB)" to reenable hugepage coredump, if a memory error happens on a hugepage and the affected processes try to access the error hugepage, we hit VM_BUG_ON(atomic_read(&page->_count) <= 0) in get_page(). The reason for this bug is that coredump-related code doesn't recognise "hugepage hwpoison entry" with which a pmd entry is replaced when a memory error occurs on a hugepage. In other words, physical address information is stored in different bit layout between hugepage hwpoison entry and pmd entry, so follow_hugetlb_page() which is called in get_dump_page() returns a wrong page from a given address. The expected behavior is like this: absent is_swap_pte FOLL_DUMP Expected behavior ------------------------------------------------------------------- true false false hugetlb_fault false true false hugetlb_fault false false false return page true false true skip page (to avoid allocation) false true true hugetlb_fault false false true return page With this patch, we can call hugetlb_fault() and take proper actions (we wait for migration entries, fail with VM_FAULT_HWPOISON_LARGE for hwpoisoned entries,) and as the result we can dump all hugepages except for hwpoisoned ones. Signed-off-by: Naoya Horiguchi Cc: Rik van Riel Acked-by: Michal Hocko Cc: HATAYAMA Daisuke Acked-by: KOSAKI Motohiro Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4f969dd6ce2941f9ce917684a058af2d7f6c77e9 Author: Christoph Fritz Date: Thu Apr 11 21:32:57 2013 +0200 can: sja1000: fix handling on dt properties on little endian systems commit 0443de5fbf224abf41f688d8487b0c307dc5a4b4 upstream. To get correct endianes on little endian cpus (like arm) while reading device tree properties, this patch replaces of_get_property() with of_property_read_u32(). While there use of_property_read_bool() for the handling of the boolean "nxp,no-comparator-bypass" property. Signed-off-by: Christoph Fritz Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 110360768eb74d67bac851b7c0209a923258a314 Author: Michael Bohan Date: Tue Mar 19 19:19:25 2013 -0700 hrtimer: Don't reinitialize a cpu_base lock on CPU_UP commit 84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0 upstream. The current code makes the assumption that a cpu_base lock won't be held if the CPU corresponding to that cpu_base is offline, which isn't always true. If a hrtimer is not queued, then it will not be migrated by migrate_hrtimers() when a CPU is offlined. Therefore, the hrtimer's cpu_base may still point to a CPU which has subsequently gone offline if the timer wasn't enqueued at the time the CPU went down. Normally this wouldn't be a problem, but a cpu_base's lock is blindly reinitialized each time a CPU is brought up. If a CPU is brought online during the period that another thread is performing a hrtimer operation on a stale hrtimer, then the lock will be reinitialized under its feet, and a SPIN_BUG() like the following will be observed: <0>[ 28.082085] BUG: spinlock already unlocked on CPU#0, swapper/0/0 <0>[ 28.087078] lock: 0xc4780b40, value 0x0 .magic: dead4ead, .owner: /-1, .owner_cpu: -1 <4>[ 42.451150] [] (unwind_backtrace+0x0/0x120) from [] (do_raw_spin_unlock+0x44/0xdc) <4>[ 42.460430] [] (do_raw_spin_unlock+0x44/0xdc) from [] (_raw_spin_unlock+0x8/0x30) <4>[ 42.469632] [] (_raw_spin_unlock+0x8/0x30) from [] (__hrtimer_start_range_ns+0x1e4/0x4f8) <4>[ 42.479521] [] (__hrtimer_start_range_ns+0x1e4/0x4f8) from [] (hrtimer_start+0x20/0x28) <4>[ 42.489247] [] (hrtimer_start+0x20/0x28) from [] (rcu_idle_enter_common+0x1ac/0x320) <4>[ 42.498709] [] (rcu_idle_enter_common+0x1ac/0x320) from [] (rcu_idle_enter+0xa0/0xb8) <4>[ 42.508259] [] (rcu_idle_enter+0xa0/0xb8) from [] (cpu_idle+0x24/0xf0) <4>[ 42.516503] [] (cpu_idle+0x24/0xf0) from [] (rest_init+0x88/0xa0) <4>[ 42.524319] [] (rest_init+0x88/0xa0) from [] (start_kernel+0x3d0/0x434) As an example, this particular crash occurred when hrtimer_start() was executed on CPU #0. The code locked the hrtimer's current cpu_base corresponding to CPU #1. CPU #0 then tried to switch the hrtimer's cpu_base to an optimal CPU which was online. In this case, it selected the cpu_base corresponding to CPU #3. Before it could proceed, CPU #1 came online and reinitialized the spinlock corresponding to its cpu_base. Thus now CPU #0 held a lock which was reinitialized. When CPU #0 finally ended up unlocking the old cpu_base corresponding to CPU #1 so that it could switch to CPU #3, we hit this SPIN_BUG() above while in switch_hrtimer_base(). CPU #0 CPU #1 ---- ---- ... hrtimer_start() lock_hrtimer_base(base #1) ... init_hrtimers_cpu() switch_hrtimer_base() ... ... raw_spin_lock_init(&cpu_base->lock) raw_spin_unlock(&cpu_base->lock) ... Solve this by statically initializing the lock. Signed-off-by: Michael Bohan Link: http://lkml.kernel.org/r/1363745965-23475-1-git-send-email-mbohan@codeaurora.org Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 816e2bb1b20b734d2e4286c12f0b18ae9dff35ab Author: Russell King Date: Mon Apr 8 11:44:57 2013 +0100 ARM: Do 15e0d9e37c (ARM: pm: let platforms select cpu_suspend support) properly commit b6c7aabd923a17af993c5a5d5d7995f0b27c000a upstream. Let's do the changes properly and fix the same problem everywhere, not just for one case. Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman