--- /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
+@@ -546,7 +546,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
+@@ -1743,7 +1743,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
+@@ -2041,6 +2041,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
+@@ -90,8 +90,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:
+ /*
+@@ -173,7 +173,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
+@@ -143,6 +143,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 = BLK_DEF_MAX_SECTORS;
+ }
--- /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,
+ },
+@@ -1504,19 +1504,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
nfsv4-fix-a-use-after-free-situation-in-_nfs4_proc_getlk.patch
nfsd-split-up-nfsd_setattr.patch
nfsd-make-sure-to-balance-get-put_write_access.patch
+x86-microcode-amd-tone-down-printk-don-t-treat-a-missing-firmware-file-as-an-error.patch
+hwmon-lm90-fix-max6696-alarm-handling.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 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
+@@ -338,7 +338,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
