--- /dev/null
+From 40c2729bab48e2832b17c1fa8af9db60e776131b Mon Sep 17 00:00:00 2001
+From: Christoffer Dall <christoffer.dall@linaro.org>
+Date: Fri, 15 Nov 2013 13:14:12 -0800
+Subject: arm/arm64: KVM: Fix hyp mappings of vmalloc regions
+
+From: Christoffer Dall <christoffer.dall@linaro.org>
+
+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 <santosh.shilimkar@ti.com>
+Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
+ /**
--- /dev/null
+From a207f5937630dd35bd2550620bef416937a1365e Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 14 Oct 2013 12:13:24 -0400
+Subject: block: fix a probe argument to blk_register_region
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+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: [<ffffffff8118b188>] __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:[<ffffffff8118b188>] [<ffffffff8118b188>] __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:
+ [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
+ [<ffffffff8118c10d>] blkdev_get+0x1dd/0x370
+ [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
+ [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
+ [<ffffffff8118c300>] ? blkdev_get_by_dev+0x60/0x60
+ [<ffffffff8118c365>] blkdev_open+0x65/0x80
+ [<ffffffff8114d12e>] do_dentry_open.isra.18+0x23e/0x2f0
+ [<ffffffff8114d214>] finish_open+0x34/0x50
+ [<ffffffff8115e122>] do_last.isra.62+0x2d2/0xc50
+ [<ffffffff8115eb58>] path_openat.isra.63+0xb8/0x4d0
+ [<ffffffff81115a8e>] ? might_fault+0x4e/0xa0
+ [<ffffffff8115f4f0>] do_filp_open+0x40/0x90
+ [<ffffffff813cea6c>] ? _raw_spin_unlock+0x2c/0x50
+ [<ffffffff8116db85>] ? __alloc_fd+0xa5/0x1f0
+ [<ffffffff8114e45f>] do_sys_open+0xef/0x1d0
+ [<ffffffff8114e559>] SyS_open+0x19/0x20
+ [<ffffffff813cff16>] 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 [<ffffffff8118b188>] __blkdev_get+0x28/0x450
+ RSP <ffff88023e47dbd8>
+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 <mpatocka@redhat.com>
+Acked-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 4912aa6c11e6a5d910264deedbec2075c6f1bb73 Mon Sep 17 00:00:00 2001
+From: Jeff Moyer <jmoyer@redhat.com>
+Date: Tue, 8 Oct 2013 14:36:41 -0400
+Subject: block: fix race between request completion and timeout handling
+
+From: Jeff Moyer <jmoyer@redhat.com>
+
+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:[<ffffffff8124e424>] [<ffffffff8124e424>] 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:
+ [<ffffffff81362323>] __scsi_queue_insert+0xa3/0x150
+ [<ffffffff8135f393>] ? scsi_eh_ready_devs+0x5e3/0x850
+ [<ffffffff81362a23>] scsi_queue_insert+0x13/0x20
+ [<ffffffff8135e4d4>] scsi_eh_flush_done_q+0x104/0x160
+ [<ffffffff8135fb6b>] scsi_error_handler+0x35b/0x660
+ [<ffffffff8135f810>] ? scsi_error_handler+0x0/0x660
+ [<ffffffff810908c6>] kthread+0x96/0xa0
+ [<ffffffff8100c14a>] child_rip+0xa/0x20
+ [<ffffffff81090830>] ? kthread+0x0/0xa0
+ [<ffffffff8100c140>] ? 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 [<ffffffff8124e424>] blk_requeue_request+0x94/0xa0
+ RSP <ffff881057eefd60>
+
+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 <jmoyer@redhat.com>
+Acked-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From d82ae52e68892338068e7559a0c0657193341ce4 Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Fri, 18 Oct 2013 09:44:49 -0600
+Subject: block: properly stack underlying max_segment_size to DM device
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+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 <l.flis@cyfronet.pl>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From a0e5a12fd18d47aa87a7a8c60ca5bc422b136564 Mon Sep 17 00:00:00 2001
+From: Roger Tseng <rogerable@realtek.com>
+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 <rogerable@realtek.com>
+
+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 <rogerable@realtek.com>
+Acked-by: Maxim Levitsky <maximlevitsky@gmail.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From ab4ead02ec235d706d0611d8741964628291237e Mon Sep 17 00:00:00 2001
+From: Kevin Hao <haokexin@gmail.com>
+Date: Wed, 23 Oct 2013 20:58:16 +0800
+Subject: ftrace/x86: skip over the breakpoint for ftrace caller
+
+From: Kevin Hao <haokexin@gmail.com>
+
+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 <haokexin@gmail.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From e41fae2b1ed8c78283d73651cd65be0228c0dd1c Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Fri, 15 Nov 2013 10:40:38 +0100
+Subject: hwmon: (lm90) Fix max6696 alarm handling
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+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 <khali@linux-fr.org>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 27ef63c7e97d1e5dddd85051c03f8d44cc887f34 Mon Sep 17 00:00:00 2001
+From: Greg Edwards <gedwards@ddn.com>
+Date: Mon, 4 Nov 2013 09:08:12 -0700
+Subject: KVM: IOMMU: hva align mapping page size
+
+From: Greg Edwards <gedwards@ddn.com>
+
+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 <mtosatti@redhat.com>
+Signed-off-by: Greg Edwards <gedwards@ddn.com>
+Signed-off-by: Gleb Natapov <gleb@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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.
--- /dev/null
+From daf727225b8abfdfe424716abac3d15a3ac5626a Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Thu, 31 Oct 2013 23:05:24 +0100
+Subject: KVM: x86: fix emulation of "movzbl %bpl, %eax"
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+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 <michele@redhat.com>
+Cc: Gleb Natapov <gleb@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Gleb Natapov <gleb@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From 522e66464467543c0d88d023336eec4df03ad40b Mon Sep 17 00:00:00 2001
+From: Fenghua Yu <fenghua.yu@intel.com>
+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 <fenghua.yu@intel.com>
+
+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 <fenghua.yu@intel.com>
+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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 11f918d3e2d3861b6931e97b3aa778e4984935aa Mon Sep 17 00:00:00 2001
+From: Thomas Renninger <trenn@suse.de>
+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 <trenn@suse.de>
+
+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 <trenn@suse.de>
+Acked-by: Borislav Petkov <bp@suse.de>
+Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.de
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
