From: Logan Gunthorpe
quoted hunk ↗ jump to hunk
Sent: 13 April 2017 23:05
Straightforward conversion to the new helper, except due to
the lack of error path, we have to warn if unmapable memory
is ever present in the sgl.
Signed-off-by: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
---
drivers/block/xen-blkfront.c | 33 +++++++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5067a0a..7dcf41d 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req, struct blkfront_ring_info *ri
BUG_ON(sg->offset + sg->length > PAGE_SIZE);
if (setup.need_copy) {
- setup.bvec_off = sg->offset;
- setup.bvec_data = kmap_atomic(sg_page(sg));
+ setup.bvec_off = 0;
+ setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
+ if (IS_ERR(setup.bvec_data)) {
+ /*
+ * This should really never happen unless
+ * the code is changed to use memory that is
+ * not mappable in the sg. Seeing there is a
+ * questionable error path out of here,
+ * we WARN.
+ */
+ WARN(1, "Non-mappable memory used in sg!");
+ return 1;
+ }
...
Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
inside sg_map().
David