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 (file)
index 0000000..fee7494
--- /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 <austin.lund@gmail.com>
+Date: Thu, 24 Jul 2014 07:40:20 -0300
+Subject: [media] media/rc: Send sync space information on the lirc
+ device
+
+From: Austin Lund <austin.lund@gmail.com>
+
+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 <austin.lund@gmail.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 (file)
index 0000000..9300986
--- /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 <elder@linaro.org>
+Date: Tue, 25 Mar 2014 15:36:02 +0200
+Subject: rbd: drop an unsafe assertion
+
+From: Alex Elder <elder@linaro.org>
+
+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 <ob@daevel.fr>
+Signed-off-by: Alex Elder <elder@linaro.org>
+Reviewed-by: Sage Weil <sage@inktank.com>
+Reviewed-by: Ilya Dryomov <ilya.dryomov@inktank.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 9b77063a918c5f487819fb99da994b48131380cc..eede573ffdfda9c7b50416e4434935ab36ba090b 100644 (file)
--- 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 (file)
index 0000000..4ac2e76
--- /dev/null
+++ b/queue-3.19/series
@@ -0,0 +1 @@
+ext4-ignore-journal-checksum-on-remount-don-t-fail.patch