From: Greg Kroah-Hartman Date: Wed, 25 Feb 2015 00:46:47 +0000 (-0800) Subject: 3.10-stable patches X-Git-Tag: v3.14.34~4 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=53265426590f23ec5da21c231eb2689a5d36311b;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: media-rc-send-sync-space-information-on-the-lirc.patch rbd-drop-an-unsafe-assertion.patch --- diff --git a/queue-3.10/media-rc-send-sync-space-information-on-the-lirc.patch b/queue-3.10/media-rc-send-sync-space-information-on-the-lirc.patch new file mode 100644 index 00000000000..fee7494818b --- /dev/null +++ b/queue-3.10/media-rc-send-sync-space-information-on-the-lirc.patch @@ -0,0 +1,49 @@ +From a8f29e89f2b54fbf2c52be341f149bc195b63a8b Mon Sep 17 00:00:00 2001 +From: Austin Lund +Date: Thu, 24 Jul 2014 07:40:20 -0300 +Subject: [media] media/rc: Send sync space information on the lirc + device + +From: Austin Lund + +commit a8f29e89f2b54fbf2c52be341f149bc195b63a8b upstream. + +Userspace expects to see a long space before the first pulse is sent on +the lirc device. Currently, if a long time has passed and a new packet +is started, the lirc codec just returns and doesn't send anything. This +makes lircd ignore many perfectly valid signals unless they are sent in +quick sucession. When a reset event is delivered, we cannot know +anything about the duration of the space. But it should be safe to +assume it has been a long time and we just set the duration to maximum. + +Signed-off-by: Austin Lund +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/rc/ir-lirc-codec.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +--- a/drivers/media/rc/ir-lirc-codec.c ++++ b/drivers/media/rc/ir-lirc-codec.c +@@ -42,11 +42,17 @@ static int ir_lirc_decode(struct rc_dev + return -EINVAL; + + /* Packet start */ +- if (ev.reset) +- return 0; ++ if (ev.reset) { ++ /* Userspace expects a long space event before the start of ++ * the signal to use as a sync. This may be done with repeat ++ * packets and normal samples. But if a reset has been sent ++ * then we assume that a long time has passed, so we send a ++ * space with the maximum time value. */ ++ sample = LIRC_SPACE(LIRC_VALUE_MASK); ++ IR_dprintk(2, "delivering reset sync space to lirc_dev\n"); + + /* Carrier reports */ +- if (ev.carrier_report) { ++ } else if (ev.carrier_report) { + sample = LIRC_FREQUENCY(ev.carrier); + IR_dprintk(2, "carrier report (freq: %d)\n", sample); + diff --git a/queue-3.10/rbd-drop-an-unsafe-assertion.patch b/queue-3.10/rbd-drop-an-unsafe-assertion.patch new file mode 100644 index 00000000000..930098637bc --- /dev/null +++ b/queue-3.10/rbd-drop-an-unsafe-assertion.patch @@ -0,0 +1,61 @@ +From 638c323c4d1f8eaf25224946e21ce8818f1bcee1 Mon Sep 17 00:00:00 2001 +From: Alex Elder +Date: Tue, 25 Mar 2014 15:36:02 +0200 +Subject: rbd: drop an unsafe assertion + +From: Alex Elder + +commit 638c323c4d1f8eaf25224946e21ce8818f1bcee1 upstream. + +Olivier Bonvalet reported having repeated crashes due to a failed +assertion he was hitting in rbd_img_obj_callback(): + + Assertion failure in rbd_img_obj_callback() at line 2165: + rbd_assert(which >= img_request->next_completion); + +With a lot of help from Olivier with reproducing the problem +we were able to determine the object and image requests had +already been completed (and often freed) at the point the +assertion failed. + +There was a great deal of discussion on the ceph-devel mailing list +about this. The problem only arose when there were two (or more) +object requests in an image request, and the problem was always +seen when the second request was being completed. + +The problem is due to a race in the window between setting the +"done" flag on an object request and checking the image request's +next completion value. When the first object request completes, it +checks to see if its successor request is marked "done", and if +so, that request is also completed. In the process, the image +request's next_completion value is updated to reflect that both +the first and second requests are completed. By the time the +second request is able to check the next_completion value, it +has been set to a value *greater* than its own "which" value, +which caused an assertion to fail. + +Fix this problem by skipping over any completion processing +unless the completing object request is the next one expected. +Test only for inequality (not >=), and eliminate the bad +assertion. + +Tested-by: Olivier Bonvalet +Signed-off-by: Alex Elder +Reviewed-by: Sage Weil +Reviewed-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/block/rbd.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/block/rbd.c ++++ b/drivers/block/rbd.c +@@ -2149,7 +2149,6 @@ static void rbd_img_obj_callback(struct + rbd_assert(img_request->obj_request_count > 0); + rbd_assert(which != BAD_WHICH); + rbd_assert(which < img_request->obj_request_count); +- rbd_assert(which >= img_request->next_completion); + + spin_lock_irq(&img_request->completion_lock); + if (which != img_request->next_completion) diff --git a/queue-3.10/series b/queue-3.10/series index 9b77063a918..eede573ffdf 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -12,3 +12,5 @@ tcp-ipv4-initialize-unicast_sock-sk_pacing_rate.patch ipv4-tcp-get-rid-of-ugly-unicast_sock.patch ppp-deflate-never-return-len-larger-than-output-buffer.patch net-sctp-fix-passing-wrong-parameter-header-to-param_type2af-in-sctp_process_param.patch +media-rc-send-sync-space-information-on-the-lirc.patch +rbd-drop-an-unsafe-assertion.patch diff --git a/queue-3.19/series b/queue-3.19/series new file mode 100644 index 00000000000..4ac2e76adda --- /dev/null +++ b/queue-3.19/series @@ -0,0 +1 @@ +ext4-ignore-journal-checksum-on-remount-don-t-fail.patch