From: Greg Kroah-Hartman Date: Tue, 26 Nov 2013 21:23:35 +0000 (-0800) Subject: 3.12-stable patches X-Git-Tag: v3.11.10~10 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=240c5941f1077c0f9f5ebc9aba43e4b4ed4d9bad;p=thirdparty%2Fkernel%2Fstable-queue.git 3.12-stable patches added patches: arm-arm64-kvm-fix-hyp-mappings-of-vmalloc-regions.patch block-fix-a-probe-argument-to-blk_register_region.patch block-fix-race-between-request-completion-and-timeout-handling.patch block-properly-stack-underlying-max_segment_size-to-dm-device.patch drivers-memstick-core-ms_block.c-fix-unreachable-state-in-h_msb_read_page.patch ftrace-x86-skip-over-the-breakpoint-for-ftrace-caller.patch hwmon-lm90-fix-max6696-alarm-handling.patch kvm-iommu-hva-align-mapping-page-size.patch kvm-x86-fix-emulation-of-movzbl-bpl-eax.patch x86-apic-disable-i-o-apic-before-shutdown-of-the-local-apic.patch x86-microcode-amd-tone-down-printk-don-t-treat-a-missing-firmware-file-as-an-error.patch --- diff --git a/queue-3.12/arm-arm64-kvm-fix-hyp-mappings-of-vmalloc-regions.patch b/queue-3.12/arm-arm64-kvm-fix-hyp-mappings-of-vmalloc-regions.patch new file mode 100644 index 00000000000..7496edeb321 --- /dev/null +++ b/queue-3.12/arm-arm64-kvm-fix-hyp-mappings-of-vmalloc-regions.patch @@ -0,0 +1,82 @@ +From 40c2729bab48e2832b17c1fa8af9db60e776131b Mon Sep 17 00:00:00 2001 +From: Christoffer Dall +Date: Fri, 15 Nov 2013 13:14:12 -0800 +Subject: arm/arm64: KVM: Fix hyp mappings of vmalloc regions + +From: Christoffer Dall + +commit 40c2729bab48e2832b17c1fa8af9db60e776131b upstream. + +Using virt_to_phys on percpu mappings is horribly wrong as it may be +backed by vmalloc. Introduce kvm_kaddr_to_phys which translates both +types of valid kernel addresses to the corresponding physical address. + +At the same time resolves a typing issue where we were storing the +physical address as a 32 bit unsigned long (on arm), truncating the +physical address for addresses above the 4GB limit. This caused +breakage on Keystone. + +Reported-by: Santosh Shilimkar +Tested-by: Santosh Shilimkar +Signed-off-by: Marc Zyngier +Signed-off-by: Christoffer Dall +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/kvm/mmu.c | 34 ++++++++++++++++++++++++++++------ + 1 file changed, 28 insertions(+), 6 deletions(-) + +--- a/arch/arm/kvm/mmu.c ++++ b/arch/arm/kvm/mmu.c +@@ -307,6 +307,17 @@ out: + return err; + } + ++static phys_addr_t kvm_kaddr_to_phys(void *kaddr) ++{ ++ if (!is_vmalloc_addr(kaddr)) { ++ BUG_ON(!virt_addr_valid(kaddr)); ++ return __pa(kaddr); ++ } else { ++ return page_to_phys(vmalloc_to_page(kaddr)) + ++ offset_in_page(kaddr); ++ } ++} ++ + /** + * create_hyp_mappings - duplicate a kernel virtual address range in Hyp mode + * @from: The virtual kernel start address of the range +@@ -318,16 +329,27 @@ out: + */ + int create_hyp_mappings(void *from, void *to) + { +- unsigned long phys_addr = virt_to_phys(from); ++ phys_addr_t phys_addr; ++ unsigned long virt_addr; + unsigned long start = KERN_TO_HYP((unsigned long)from); + unsigned long end = KERN_TO_HYP((unsigned long)to); + +- /* Check for a valid kernel memory mapping */ +- if (!virt_addr_valid(from) || !virt_addr_valid(to - 1)) +- return -EINVAL; ++ start = start & PAGE_MASK; ++ end = PAGE_ALIGN(end); ++ ++ for (virt_addr = start; virt_addr < end; virt_addr += PAGE_SIZE) { ++ int err; ++ ++ phys_addr = kvm_kaddr_to_phys(from + virt_addr - start); ++ err = __create_hyp_mappings(hyp_pgd, virt_addr, ++ virt_addr + PAGE_SIZE, ++ __phys_to_pfn(phys_addr), ++ PAGE_HYP); ++ if (err) ++ return err; ++ } + +- return __create_hyp_mappings(hyp_pgd, start, end, +- __phys_to_pfn(phys_addr), PAGE_HYP); ++ return 0; + } + + /** diff --git a/queue-3.12/block-fix-a-probe-argument-to-blk_register_region.patch b/queue-3.12/block-fix-a-probe-argument-to-blk_register_region.patch new file mode 100644 index 00000000000..fe0ac93c7b9 --- /dev/null +++ b/queue-3.12/block-fix-a-probe-argument-to-blk_register_region.patch @@ -0,0 +1,101 @@ +From a207f5937630dd35bd2550620bef416937a1365e Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Mon, 14 Oct 2013 12:13:24 -0400 +Subject: block: fix a probe argument to blk_register_region + +From: Mikulas Patocka + +commit a207f5937630dd35bd2550620bef416937a1365e upstream. + +The probe function is supposed to return NULL on failure (as we can see in +kobj_lookup: kobj = probe(dev, index, data); ... if (kobj) return kobj; + +However, in loop and brd, it returns negative error from ERR_PTR. + +This causes a crash if we simulate disk allocation failure and run +less -f /dev/loop0 because the negative number is interpreted as a pointer: + +BUG: unable to handle kernel NULL pointer dereference at 00000000000002b4 +IP: [] __blkdev_get+0x28/0x450 +PGD 23c677067 PUD 23d6d1067 PMD 0 +Oops: 0000 [#1] PREEMPT SMP +Modules linked in: loop hpfs nvidia(PO) ip6table_filter ip6_tables uvesafb cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit fbcon_rotate fbcon_cw fbcon_ud fbcon_ccw softcursor fb fbdev msr ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc tun ipv6 cpufreq_stats cpufreq_ondemand cpufreq_userspace cpufreq_powersave cpufreq_conservative hid_generic spadfs usbhid hid fuse raid0 snd_usb_audio snd_pcm_oss snd_mixer_oss md_mod snd_pcm snd_timer snd_page_alloc snd_hwdep snd_usbmidi_lib dmi_sysfs snd_rawmidi nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack snd soundcore lm85 hwmon_vid ohci_hcd ehci_pci ehci_hcd serverworks sata_svw libata acpi_cpufreq freq_table mperf ide_core usbcore kvm_amd kvm tg3 i2c_piix4 libphy microcode e100 usb_common ptp skge i2c_core pcspkr k10temp evdev floppy hwmon pps_core mii rtc_cmos button processor unix [last unloaded: nvidia] +CPU: 1 PID: 6831 Comm: less Tainted: P W O 3.10.15-devel #18 +Hardware name: empty empty/S3992-E, BIOS 'V1.06 ' 06/09/2009 +task: ffff880203cc6bc0 ti: ffff88023e47c000 task.ti: ffff88023e47c000 +RIP: 0010:[] [] __blkdev_get+0x28/0x450 +RSP: 0018:ffff88023e47dbd8 EFLAGS: 00010286 +RAX: ffffffffffffff74 RBX: ffffffffffffff74 RCX: 0000000000000000 +RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 +RBP: ffff88023e47dc18 R08: 0000000000000002 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000000 R12: ffff88023f519658 +R13: ffffffff8118c300 R14: 0000000000000000 R15: ffff88023f519640 +FS: 00007f2070bf7700(0000) GS:ffff880247400000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00000000000002b4 CR3: 000000023da1d000 CR4: 00000000000007e0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +Stack: + 0000000000000002 0000001d00000000 000000003e47dc50 ffff88023f519640 + ffff88043d5bb668 ffffffff8118c300 ffff88023d683550 ffff88023e47de60 + ffff88023e47dc98 ffffffff8118c10d 0000001d81605698 0000000000000292 +Call Trace: + [] ? blkdev_get_by_dev+0x60/0x60 + [] blkdev_get+0x1dd/0x370 + [] ? blkdev_get_by_dev+0x60/0x60 + [] ? _raw_spin_unlock+0x2c/0x50 + [] ? blkdev_get_by_dev+0x60/0x60 + [] blkdev_open+0x65/0x80 + [] do_dentry_open.isra.18+0x23e/0x2f0 + [] finish_open+0x34/0x50 + [] do_last.isra.62+0x2d2/0xc50 + [] path_openat.isra.63+0xb8/0x4d0 + [] ? might_fault+0x4e/0xa0 + [] do_filp_open+0x40/0x90 + [] ? _raw_spin_unlock+0x2c/0x50 + [] ? __alloc_fd+0xa5/0x1f0 + [] do_sys_open+0xef/0x1d0 + [] SyS_open+0x19/0x20 + [] system_call_fastpath+0x1a/0x1f +Code: 44 00 00 55 48 89 e5 41 57 49 89 ff 41 56 41 89 d6 41 55 41 54 4c 8d 67 18 53 48 83 ec 18 89 75 cc e9 f2 00 00 00 0f 1f 44 00 00 <48> 8b 80 40 03 00 00 48 89 df 4c 8b 68 58 e8 d5 +a4 07 00 44 89 +RIP [] __blkdev_get+0x28/0x450 + RSP +CR2: 00000000000002b4 +---[ end trace bb7f32dbf02398dc ]--- + +The brd change should be backported to stable kernels starting with 2.6.25. +The loop change should be backported to stable kernels starting with 2.6.22. + +Signed-off-by: Mikulas Patocka +Acked-by: Tejun Heo +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/block/brd.c | 2 +- + drivers/block/loop.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/block/brd.c ++++ b/drivers/block/brd.c +@@ -545,7 +545,7 @@ static struct kobject *brd_probe(dev_t d + + mutex_lock(&brd_devices_mutex); + brd = brd_init_one(MINOR(dev) >> part_shift); +- kobj = brd ? get_disk(brd->brd_disk) : ERR_PTR(-ENOMEM); ++ kobj = brd ? get_disk(brd->brd_disk) : NULL; + mutex_unlock(&brd_devices_mutex); + + *part = 0; +--- a/drivers/block/loop.c ++++ b/drivers/block/loop.c +@@ -1741,7 +1741,7 @@ static struct kobject *loop_probe(dev_t + if (err < 0) + err = loop_add(&lo, MINOR(dev) >> part_shift); + if (err < 0) +- kobj = ERR_PTR(err); ++ kobj = NULL; + else + kobj = get_disk(lo->lo_disk); + mutex_unlock(&loop_index_mutex); diff --git a/queue-3.12/block-fix-race-between-request-completion-and-timeout-handling.patch b/queue-3.12/block-fix-race-between-request-completion-and-timeout-handling.patch new file mode 100644 index 00000000000..b6dc6dcbc85 --- /dev/null +++ b/queue-3.12/block-fix-race-between-request-completion-and-timeout-handling.patch @@ -0,0 +1,135 @@ +From 4912aa6c11e6a5d910264deedbec2075c6f1bb73 Mon Sep 17 00:00:00 2001 +From: Jeff Moyer +Date: Tue, 8 Oct 2013 14:36:41 -0400 +Subject: block: fix race between request completion and timeout handling + +From: Jeff Moyer + +commit 4912aa6c11e6a5d910264deedbec2075c6f1bb73 upstream. + +crocode i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma dca be2net sg ses enclosure ext4 mbcache jbd2 sd_mod crc_t10dif ahci megaraid_sas(U) dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan] + +Pid: 491, comm: scsi_eh_0 Tainted: G W ---------------- 2.6.32-220.13.1.el6.x86_64 #1 IBM -[8722PAX]-/00D1461 +RIP: 0010:[] [] blk_requeue_request+0x94/0xa0 +RSP: 0018:ffff881057eefd60 EFLAGS: 00010012 +RAX: ffff881d99e3e8a8 RBX: ffff881d99e3e780 RCX: ffff881d99e3e8a8 +RDX: ffff881d99e3e8a8 RSI: ffff881d99e3e780 RDI: ffff881d99e3e780 +RBP: ffff881057eefd80 R08: ffff881057eefe90 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000000 R12: ffff881057f92338 +R13: 0000000000000000 R14: ffff881057f92338 R15: ffff883058188000 +FS: 0000000000000000(0000) GS:ffff880040200000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b +CR2: 00000000006d3ec0 CR3: 000000302cd7d000 CR4: 00000000000406b0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +Process scsi_eh_0 (pid: 491, threadinfo ffff881057eee000, task ffff881057e29540) +Stack: + 0000000000001057 0000000000000286 ffff8810275efdc0 ffff881057f16000 +<0> ffff881057eefdd0 ffffffff81362323 ffff881057eefe20 ffffffff8135f393 +<0> ffff881057e29af8 ffff8810275efdc0 ffff881057eefe78 ffff881057eefe90 +Call Trace: + [] __scsi_queue_insert+0xa3/0x150 + [] ? scsi_eh_ready_devs+0x5e3/0x850 + [] scsi_queue_insert+0x13/0x20 + [] scsi_eh_flush_done_q+0x104/0x160 + [] scsi_error_handler+0x35b/0x660 + [] ? scsi_error_handler+0x0/0x660 + [] kthread+0x96/0xa0 + [] child_rip+0xa/0x20 + [] ? kthread+0x0/0xa0 + [] ? child_rip+0x0/0x20 +Code: 00 00 eb d1 4c 8b 2d 3c 8f 97 00 4d 85 ed 74 bf 49 8b 45 00 49 83 c5 08 48 89 de 4c 89 e7 ff d0 49 8b 45 00 48 85 c0 75 eb eb a4 <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 +RIP [] blk_requeue_request+0x94/0xa0 + RSP + +The RIP is this line: + BUG_ON(blk_queued_rq(rq)); + +After digging through the code, I think there may be a race between the +request completion and the timer handler running. + +A timer is started for each request put on the device's queue (see +blk_start_request->blk_add_timer). If the request does not complete +before the timer expires, the timer handler (blk_rq_timed_out_timer) +will mark the request complete atomically: + +static inline int blk_mark_rq_complete(struct request *rq) +{ + return test_and_set_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags); +} + +and then call blk_rq_timed_out. The latter function will call +scsi_times_out, which will return one of BLK_EH_HANDLED, +BLK_EH_RESET_TIMER or BLK_EH_NOT_HANDLED. If BLK_EH_RESET_TIMER is +returned, blk_clear_rq_complete is called, and blk_add_timer is again +called to simply wait longer for the request to complete. + +Now, if the request happens to complete while this is going on, what +happens? Given that we know the completion handler will bail if it +finds the REQ_ATOM_COMPLETE bit set, we need to focus on the completion +handler running after that bit is cleared. So, from the above +paragraph, after the call to blk_clear_rq_complete. If the completion +sets REQ_ATOM_COMPLETE before the BUG_ON in blk_add_timer, we go boom +there (I haven't seen this in the cores). Next, if we get the +completion before the call to list_add_tail, then the timer will +eventually fire for an old req, which may either be freed or reallocated +(there is evidence that this might be the case). Finally, if the +completion comes in *after* the addition to the timeout list, I think +it's harmless. The request will be removed from the timeout list, +req_atom_complete will be set, and all will be well. + +This will only actually explain the coredumps *IF* the request +structure was freed, reallocated *and* queued before the error handler +thread had a chance to process it. That is possible, but it may make +sense to keep digging for another race. I think that if this is what +was happening, we would see other instances of this problem showing up +as null pointer or garbage pointer dereferences, for example when the +request structure was not re-used. It looks like we actually do run +into that situation in other reports. + +This patch moves the BUG_ON(test_bit(REQ_ATOM_COMPLETE, +&req->atomic_flags)); from blk_add_timer to the only caller that could +trip over it (blk_start_request). It then inverts the calls to +blk_clear_rq_complete and blk_add_timer in blk_rq_timed_out to address +the race. I've boot tested this patch, but nothing more. + +Signed-off-by: Jeff Moyer +Acked-by: Hannes Reinecke +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/blk-core.c | 1 + + block/blk-timeout.c | 3 +-- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/block/blk-core.c ++++ b/block/blk-core.c +@@ -2227,6 +2227,7 @@ void blk_start_request(struct request *r + if (unlikely(blk_bidi_rq(req))) + req->next_rq->resid_len = blk_rq_bytes(req->next_rq); + ++ BUG_ON(test_bit(REQ_ATOM_COMPLETE, &req->atomic_flags)); + blk_add_timer(req); + } + EXPORT_SYMBOL(blk_start_request); +--- a/block/blk-timeout.c ++++ b/block/blk-timeout.c +@@ -91,8 +91,8 @@ static void blk_rq_timed_out(struct requ + __blk_complete_request(req); + break; + case BLK_EH_RESET_TIMER: +- blk_clear_rq_complete(req); + blk_add_timer(req); ++ blk_clear_rq_complete(req); + break; + case BLK_EH_NOT_HANDLED: + /* +@@ -174,7 +174,6 @@ void blk_add_timer(struct request *req) + return; + + BUG_ON(!list_empty(&req->timeout_list)); +- BUG_ON(test_bit(REQ_ATOM_COMPLETE, &req->atomic_flags)); + + /* + * Some LLDs, like scsi, peek at the timeout to prevent a diff --git a/queue-3.12/block-properly-stack-underlying-max_segment_size-to-dm-device.patch b/queue-3.12/block-properly-stack-underlying-max_segment_size-to-dm-device.patch new file mode 100644 index 00000000000..32312792c51 --- /dev/null +++ b/queue-3.12/block-properly-stack-underlying-max_segment_size-to-dm-device.patch @@ -0,0 +1,41 @@ +From d82ae52e68892338068e7559a0c0657193341ce4 Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Fri, 18 Oct 2013 09:44:49 -0600 +Subject: block: properly stack underlying max_segment_size to DM device + +From: Mike Snitzer + +commit d82ae52e68892338068e7559a0c0657193341ce4 upstream. + +Without this patch all DM devices will default to BLK_MAX_SEGMENT_SIZE +(65536) even if the underlying device(s) have a larger value -- this is +due to blk_stack_limits() using min_not_zero() when stacking the +max_segment_size limit. + +1073741824 + +before patch: +65536 + +after patch: +1073741824 + +Reported-by: Lukasz Flis +Signed-off-by: Mike Snitzer +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/blk-settings.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/block/blk-settings.c ++++ b/block/blk-settings.c +@@ -144,6 +144,7 @@ void blk_set_stacking_limits(struct queu + lim->discard_zeroes_data = 1; + lim->max_segments = USHRT_MAX; + lim->max_hw_sectors = UINT_MAX; ++ lim->max_segment_size = UINT_MAX; + lim->max_sectors = UINT_MAX; + lim->max_write_same_sectors = UINT_MAX; + } diff --git a/queue-3.12/drivers-memstick-core-ms_block.c-fix-unreachable-state-in-h_msb_read_page.patch b/queue-3.12/drivers-memstick-core-ms_block.c-fix-unreachable-state-in-h_msb_read_page.patch new file mode 100644 index 00000000000..db7ca3935d0 --- /dev/null +++ b/queue-3.12/drivers-memstick-core-ms_block.c-fix-unreachable-state-in-h_msb_read_page.patch @@ -0,0 +1,38 @@ +From a0e5a12fd18d47aa87a7a8c60ca5bc422b136564 Mon Sep 17 00:00:00 2001 +From: Roger Tseng +Date: Tue, 12 Nov 2013 15:11:40 -0800 +Subject: drivers/memstick/core/ms_block.c: fix unreachable state in h_msb_read_page() + +From: Roger Tseng + +commit a0e5a12fd18d47aa87a7a8c60ca5bc422b136564 upstream. + +In h_msb_read_page() in ms_block.c, flow never reaches case +MSB_RP_RECIVE_STATUS_REG. This causes error when MEMSTICK_INT_ERR is +encountered and status error bits are going to be examined, but the status +will never be copied back. + +Fix it by transitioning to MSB_RP_RECIVE_STATUS_REG right after +MSB_RP_SEND_READ_STATUS_REG. + +Signed-off-by: Roger Tseng +Acked-by: Maxim Levitsky +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/memstick/core/ms_block.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/memstick/core/ms_block.c ++++ b/drivers/memstick/core/ms_block.c +@@ -401,7 +401,7 @@ again: + sizeof(struct ms_status_register))) + return 0; + +- msb->state = MSB_RP_RECEIVE_OOB_READ; ++ msb->state = MSB_RP_RECIVE_STATUS_REG; + return 0; + + case MSB_RP_RECIVE_STATUS_REG: diff --git a/queue-3.12/ftrace-x86-skip-over-the-breakpoint-for-ftrace-caller.patch b/queue-3.12/ftrace-x86-skip-over-the-breakpoint-for-ftrace-caller.patch new file mode 100644 index 00000000000..4213280b242 --- /dev/null +++ b/queue-3.12/ftrace-x86-skip-over-the-breakpoint-for-ftrace-caller.patch @@ -0,0 +1,55 @@ +From ab4ead02ec235d706d0611d8741964628291237e Mon Sep 17 00:00:00 2001 +From: Kevin Hao +Date: Wed, 23 Oct 2013 20:58:16 +0800 +Subject: ftrace/x86: skip over the breakpoint for ftrace caller + +From: Kevin Hao + +commit ab4ead02ec235d706d0611d8741964628291237e upstream. + +In commit 8a4d0a687a59 "ftrace: Use breakpoint method to update ftrace +caller", we choose to use breakpoint method to update the ftrace +caller. But we also need to skip over the breakpoint in function +ftrace_int3_handler() for them. Otherwise weird things would happen. + +Signed-off-by: Kevin Hao +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/ftrace.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +--- a/arch/x86/kernel/ftrace.c ++++ b/arch/x86/kernel/ftrace.c +@@ -248,6 +248,15 @@ int ftrace_update_ftrace_func(ftrace_fun + return ret; + } + ++static int is_ftrace_caller(unsigned long ip) ++{ ++ if (ip == (unsigned long)(&ftrace_call) || ++ ip == (unsigned long)(&ftrace_regs_call)) ++ return 1; ++ ++ return 0; ++} ++ + /* + * A breakpoint was added to the code address we are about to + * modify, and this is the handle that will just skip over it. +@@ -257,10 +266,13 @@ int ftrace_update_ftrace_func(ftrace_fun + */ + int ftrace_int3_handler(struct pt_regs *regs) + { ++ unsigned long ip; ++ + if (WARN_ON_ONCE(!regs)) + return 0; + +- if (!ftrace_location(regs->ip - 1)) ++ ip = regs->ip - 1; ++ if (!ftrace_location(ip) && !is_ftrace_caller(ip)) + return 0; + + regs->ip += MCOUNT_INSN_SIZE - 1; diff --git a/queue-3.12/hwmon-lm90-fix-max6696-alarm-handling.patch b/queue-3.12/hwmon-lm90-fix-max6696-alarm-handling.patch new file mode 100644 index 00000000000..82bdc1cebc5 --- /dev/null +++ b/queue-3.12/hwmon-lm90-fix-max6696-alarm-handling.patch @@ -0,0 +1,64 @@ +From e41fae2b1ed8c78283d73651cd65be0228c0dd1c Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Fri, 15 Nov 2013 10:40:38 +0100 +Subject: hwmon: (lm90) Fix max6696 alarm handling + +From: Guenter Roeck + +commit e41fae2b1ed8c78283d73651cd65be0228c0dd1c upstream. + +Bit 2 of status register 2 on MAX6696 (external diode 2 open) +sets ALERT; the bit thus has to be listed in alert_alarms. +Also display a message in the alert handler if the condition +is encountered. + +Even though not all overtemperature conditions cause ALERT +to be set, we should not ignore them in the alert handler. +Display messages for all out-of-range conditions. + +Reported-by: Jean Delvare +Signed-off-by: Guenter Roeck +Signed-off-by: Jean Delvare +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwmon/lm90.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +--- a/drivers/hwmon/lm90.c ++++ b/drivers/hwmon/lm90.c +@@ -278,7 +278,7 @@ static const struct lm90_params lm90_par + [max6696] = { + .flags = LM90_HAVE_EMERGENCY + | LM90_HAVE_EMERGENCY_ALARM | LM90_HAVE_TEMP3, +- .alert_alarms = 0x187c, ++ .alert_alarms = 0x1c7c, + .max_convrate = 6, + .reg_local_ext = MAX6657_REG_R_LOCAL_TEMPL, + }, +@@ -1500,19 +1500,22 @@ static void lm90_alert(struct i2c_client + if ((alarms & 0x7f) == 0 && (alarms2 & 0xfe) == 0) { + dev_info(&client->dev, "Everything OK\n"); + } else { +- if (alarms & 0x61) ++ if ((alarms & 0x61) || (alarms2 & 0x80)) + dev_warn(&client->dev, + "temp%d out of range, please check!\n", 1); +- if (alarms & 0x1a) ++ if ((alarms & 0x1a) || (alarms2 & 0x20)) + dev_warn(&client->dev, + "temp%d out of range, please check!\n", 2); + if (alarms & 0x04) + dev_warn(&client->dev, + "temp%d diode open, please check!\n", 2); + +- if (alarms2 & 0x18) ++ if (alarms2 & 0x5a) + dev_warn(&client->dev, + "temp%d out of range, please check!\n", 3); ++ if (alarms2 & 0x04) ++ dev_warn(&client->dev, ++ "temp%d diode open, please check!\n", 3); + + /* + * Disable ALERT# output, because these chips don't implement diff --git a/queue-3.12/kvm-iommu-hva-align-mapping-page-size.patch b/queue-3.12/kvm-iommu-hva-align-mapping-page-size.patch new file mode 100644 index 00000000000..18abea42a91 --- /dev/null +++ b/queue-3.12/kvm-iommu-hva-align-mapping-page-size.patch @@ -0,0 +1,49 @@ +From 27ef63c7e97d1e5dddd85051c03f8d44cc887f34 Mon Sep 17 00:00:00 2001 +From: Greg Edwards +Date: Mon, 4 Nov 2013 09:08:12 -0700 +Subject: KVM: IOMMU: hva align mapping page size + +From: Greg Edwards + +commit 27ef63c7e97d1e5dddd85051c03f8d44cc887f34 upstream. + +When determining the page size we could use to map with the IOMMU, the +page size should also be aligned with the hva, not just the gfn. The +gfn may not reflect the real alignment within the hugetlbfs file. + +Most of the time, this works fine. However, if the hugetlbfs file is +backed by non-contiguous huge pages, a multi-huge page memslot starts at +an unaligned offset within the hugetlbfs file, and the gfn is aligned +with respect to the huge page size, kvm_host_page_size() will return the +huge page size and we will use that to map with the IOMMU. + +When we later unpin that same memslot, the IOMMU returns the unmap size +as the huge page size, and we happily unpin that many pfns in +monotonically increasing order, not realizing we are spanning +non-contiguous huge pages and partially unpin the wrong huge page. + +Ensure the IOMMU mapping page size is aligned with the hva corresponding +to the gfn, which does reflect the alignment within the hugetlbfs file. + +Reviewed-by: Marcelo Tosatti +Signed-off-by: Greg Edwards +Signed-off-by: Gleb Natapov +Signed-off-by: Greg Kroah-Hartman + +--- + virt/kvm/iommu.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/virt/kvm/iommu.c ++++ b/virt/kvm/iommu.c +@@ -103,6 +103,10 @@ int kvm_iommu_map_pages(struct kvm *kvm, + while ((gfn << PAGE_SHIFT) & (page_size - 1)) + page_size >>= 1; + ++ /* Make sure hva is aligned to the page size we want to map */ ++ while (__gfn_to_hva_memslot(slot, gfn) & (page_size - 1)) ++ page_size >>= 1; ++ + /* + * Pin all pages we are about to map in memory. This is + * important because we unmap and unpin in 4kb steps later. diff --git a/queue-3.12/kvm-x86-fix-emulation-of-movzbl-bpl-eax.patch b/queue-3.12/kvm-x86-fix-emulation-of-movzbl-bpl-eax.patch new file mode 100644 index 00000000000..1f4511aab98 --- /dev/null +++ b/queue-3.12/kvm-x86-fix-emulation-of-movzbl-bpl-eax.patch @@ -0,0 +1,50 @@ +From daf727225b8abfdfe424716abac3d15a3ac5626a Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Thu, 31 Oct 2013 23:05:24 +0100 +Subject: KVM: x86: fix emulation of "movzbl %bpl, %eax" + +From: Paolo Bonzini + +commit daf727225b8abfdfe424716abac3d15a3ac5626a upstream. + +When I was looking at RHEL5.9's failure to start with +unrestricted_guest=0/emulate_invalid_guest_state=1, I got it working with a +slightly older tree than kvm.git. I now debugged the remaining failure, +which was introduced by commit 660696d1 (KVM: X86 emulator: fix +source operand decoding for 8bit mov[zs]x instructions, 2013-04-24) +introduced a similar mis-emulation to the one in commit 8acb4207 (KVM: +fix sil/dil/bpl/spl in the mod/rm fields, 2013-05-30). The incorrect +decoding occurs in 8-bit movzx/movsx instructions whose 8-bit operand +is sil/dil/bpl/spl. + +Needless to say, "movzbl %bpl, %eax" does occur in RHEL5.9's decompression +prolog, just a handful of instructions before finally giving control to +the decompressed vmlinux and getting out of the invalid guest state. + +Because OpMem8 bypasses decode_modrm, the same handling of the REX prefix +must be applied to OpMem8. + +Reported-by: Michele Baldessari +Cc: Gleb Natapov +Signed-off-by: Paolo Bonzini +Signed-off-by: Gleb Natapov +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/emulate.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/emulate.c ++++ b/arch/x86/kvm/emulate.c +@@ -4040,7 +4040,10 @@ static int decode_operand(struct x86_emu + case OpMem8: + ctxt->memop.bytes = 1; + if (ctxt->memop.type == OP_REG) { +- ctxt->memop.addr.reg = decode_register(ctxt, ctxt->modrm_rm, 1); ++ int highbyte_regs = ctxt->rex_prefix == 0; ++ ++ ctxt->memop.addr.reg = decode_register(ctxt, ctxt->modrm_rm, ++ highbyte_regs); + fetch_register_operand(&ctxt->memop); + } + goto mem_common; diff --git a/queue-3.12/series b/queue-3.12/series index 95d351eb9fe..a515c9242e4 100644 --- a/queue-3.12/series +++ b/queue-3.12/series @@ -71,3 +71,14 @@ nfs-don-t-retry-detect_trunking-with-rpc_auth_unix-more-than-once.patch nfsd-split-up-nfsd_setattr.patch nfsd-make-sure-to-balance-get-put_write_access.patch nfsd4-fix-xdr-decoding-of-large-non-write-compounds.patch +x86-apic-disable-i-o-apic-before-shutdown-of-the-local-apic.patch +x86-microcode-amd-tone-down-printk-don-t-treat-a-missing-firmware-file-as-an-error.patch +kvm-x86-fix-emulation-of-movzbl-bpl-eax.patch +ftrace-x86-skip-over-the-breakpoint-for-ftrace-caller.patch +kvm-iommu-hva-align-mapping-page-size.patch +arm-arm64-kvm-fix-hyp-mappings-of-vmalloc-regions.patch +hwmon-lm90-fix-max6696-alarm-handling.patch +drivers-memstick-core-ms_block.c-fix-unreachable-state-in-h_msb_read_page.patch +block-fix-race-between-request-completion-and-timeout-handling.patch +block-fix-a-probe-argument-to-blk_register_region.patch +block-properly-stack-underlying-max_segment_size-to-dm-device.patch diff --git a/queue-3.12/x86-apic-disable-i-o-apic-before-shutdown-of-the-local-apic.patch b/queue-3.12/x86-apic-disable-i-o-apic-before-shutdown-of-the-local-apic.patch new file mode 100644 index 00000000000..21ee671b358 --- /dev/null +++ b/queue-3.12/x86-apic-disable-i-o-apic-before-shutdown-of-the-local-apic.patch @@ -0,0 +1,66 @@ +From 522e66464467543c0d88d023336eec4df03ad40b Mon Sep 17 00:00:00 2001 +From: Fenghua Yu +Date: Wed, 23 Oct 2013 18:30:12 -0700 +Subject: x86/apic: Disable I/O APIC before shutdown of the local APIC + +From: Fenghua Yu + +commit 522e66464467543c0d88d023336eec4df03ad40b upstream. + +In reboot and crash path, when we shut down the local APIC, the I/O APIC is +still active. This may cause issues because external interrupts +can still come in and disturb the local APIC during shutdown process. + +To quiet external interrupts, disable I/O APIC before shutdown local APIC. + +Signed-off-by: Fenghua Yu +Link: http://lkml.kernel.org/r/1382578212-4677-1-git-send-email-fenghua.yu@intel.com +[ I suppose the 'issue' is a hang during shutdown. It's a fine change nevertheless. ] +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/crash.c | 2 +- + arch/x86/kernel/reboot.c | 8 ++++---- + 2 files changed, 5 insertions(+), 5 deletions(-) + +--- a/arch/x86/kernel/crash.c ++++ b/arch/x86/kernel/crash.c +@@ -127,12 +127,12 @@ void native_machine_crash_shutdown(struc + cpu_emergency_vmxoff(); + cpu_emergency_svm_disable(); + +- lapic_shutdown(); + #ifdef CONFIG_X86_IO_APIC + /* Prevent crash_kexec() from deadlocking on ioapic_lock. */ + ioapic_zap_locks(); + disable_IO_APIC(); + #endif ++ lapic_shutdown(); + #ifdef CONFIG_HPET_TIMER + hpet_disable(); + #endif +--- a/arch/x86/kernel/reboot.c ++++ b/arch/x86/kernel/reboot.c +@@ -550,6 +550,10 @@ static void native_machine_emergency_res + void native_machine_shutdown(void) + { + /* Stop the cpus and apics */ ++#ifdef CONFIG_X86_IO_APIC ++ disable_IO_APIC(); ++#endif ++ + #ifdef CONFIG_SMP + /* + * Stop all of the others. Also disable the local irq to +@@ -562,10 +566,6 @@ void native_machine_shutdown(void) + + lapic_shutdown(); + +-#ifdef CONFIG_X86_IO_APIC +- disable_IO_APIC(); +-#endif +- + #ifdef CONFIG_HPET_TIMER + hpet_disable(); + #endif diff --git a/queue-3.12/x86-microcode-amd-tone-down-printk-don-t-treat-a-missing-firmware-file-as-an-error.patch b/queue-3.12/x86-microcode-amd-tone-down-printk-don-t-treat-a-missing-firmware-file-as-an-error.patch new file mode 100644 index 00000000000..8ec0963c626 --- /dev/null +++ b/queue-3.12/x86-microcode-amd-tone-down-printk-don-t-treat-a-missing-firmware-file-as-an-error.patch @@ -0,0 +1,39 @@ +From 11f918d3e2d3861b6931e97b3aa778e4984935aa Mon Sep 17 00:00:00 2001 +From: Thomas Renninger +Date: Tue, 12 Nov 2013 17:39:43 +0100 +Subject: x86/microcode/amd: Tone down printk(), don't treat a missing firmware file as an error + +From: Thomas Renninger + +commit 11f918d3e2d3861b6931e97b3aa778e4984935aa upstream. + +Do it the same way as done in microcode_intel.c: use pr_debug() +for missing firmware files. + +There seem to be CPUs out there for which no microcode update +has been submitted to kernel-firmware repo yet resulting in +scary sounding error messages in dmesg: + + microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin + +Signed-off-by: Thomas Renninger +Acked-by: Borislav Petkov +Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.de +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/microcode_amd.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/microcode_amd.c ++++ b/arch/x86/kernel/microcode_amd.c +@@ -431,7 +431,7 @@ static enum ucode_state request_microcod + snprintf(fw_name, sizeof(fw_name), "amd-ucode/microcode_amd_fam%.2xh.bin", c->x86); + + if (request_firmware(&fw, (const char *)fw_name, device)) { +- pr_err("failed to load file %s\n", fw_name); ++ pr_debug("failed to load file %s\n", fw_name); + goto out; + } +