[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150511175453.256050146@linuxfoundation.org>
Date: Mon, 11 May 2015 10:55:23 -0700
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, Alex Elder <elder@...aro.org>,
Shawn Edwards <lesser.evil@...il.com>,
Sage Weil <sage@...hat.com>, Ilya Dryomov <idryomov@...il.com>
Subject: [PATCH 3.10 08/19] rbd: end I/O the entire obj_request on error
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilya Dryomov <idryomov@...il.com>
commit 082a75dad84d79d1c15ea9e50f31cb4bb4fa7fd6 upstream.
When we end I/O struct request with error, we need to pass
obj_request->length as @nr_bytes so that the entire obj_request worth
of bytes is completed. Otherwise block layer ends up confused and we
trip on
rbd_assert(more ^ (which == img_request->obj_request_count));
in rbd_img_obj_callback() due to more being true no matter what. We
already do it in most cases but we are missing some, in particular
those where we don't even get a chance to submit any obj_requests, due
to an early -ENOMEM for example.
A number of obj_request->xferred assignments seem to be redundant but
I haven't touched any of obj_request->xferred stuff to keep this small
and isolated.
Cc: Alex Elder <elder@...aro.org>
Reported-by: Shawn Edwards <lesser.evil@...il.com>
Reviewed-by: Sage Weil <sage@...hat.com>
Signed-off-by: Ilya Dryomov <idryomov@...il.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
drivers/block/rbd.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -2115,6 +2115,11 @@ static bool rbd_img_obj_end_request(stru
result, xferred);
if (!img_request->result)
img_request->result = result;
+ /*
+ * Need to end I/O on the entire obj_request worth of
+ * bytes in case of error.
+ */
+ xferred = obj_request->length;
}
/* Image object requests don't own their page array */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists