RE: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
From: David Laight <hidden>
Date: 2017-04-18 14:14:17
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@deltatee.com> --- 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