From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-mtd@lists.infradead.org
Subject: [PATCH 01/12] block: move blk_rq_err_bytes to scsi
Date: Mon, 25 Oct 2021 09:05:06 +0200 [thread overview]
Message-ID: <20211025070517.1548584-2-hch@lst.de> (raw)
In-Reply-To: <20211025070517.1548584-1-hch@lst.de>
blk_rq_err_bytes is only used by the scsi midlayer, so move it there.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
block/blk-core.c | 41 ----------------------------------------
drivers/scsi/scsi_lib.c | 42 ++++++++++++++++++++++++++++++++++++++++-
include/linux/blk-mq.h | 3 ---
3 files changed, 41 insertions(+), 45 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 5ffe05b1d17ce..3edc5c5178dd6 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1221,47 +1221,6 @@ blk_status_t blk_insert_cloned_request(struct request_queue *q, struct request *
}
EXPORT_SYMBOL_GPL(blk_insert_cloned_request);
-/**
- * blk_rq_err_bytes - determine number of bytes till the next failure boundary
- * @rq: request to examine
- *
- * Description:
- * A request could be merge of IOs which require different failure
- * handling. This function determines the number of bytes which
- * can be failed from the beginning of the request without
- * crossing into area which need to be retried further.
- *
- * Return:
- * The number of bytes to fail.
- */
-unsigned int blk_rq_err_bytes(const struct request *rq)
-{
- unsigned int ff = rq->cmd_flags & REQ_FAILFAST_MASK;
- unsigned int bytes = 0;
- struct bio *bio;
-
- if (!(rq->rq_flags & RQF_MIXED_MERGE))
- return blk_rq_bytes(rq);
-
- /*
- * Currently the only 'mixing' which can happen is between
- * different fastfail types. We can safely fail portions
- * which have all the failfast bits that the first one has -
- * the ones which are at least as eager to fail as the first
- * one.
- */
- for (bio = rq->bio; bio; bio = bio->bi_next) {
- if ((bio->bi_opf & ff) != ff)
- break;
- bytes += bio->bi_iter.bi_size;
- }
-
- /* this could lead to infinite loop */
- BUG_ON(blk_rq_bytes(rq) && !bytes);
- return bytes;
-}
-EXPORT_SYMBOL_GPL(blk_rq_err_bytes);
-
static void update_io_ticks(struct block_device *part, unsigned long now,
bool end)
{
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9823b65d15368..1f7e68699941f 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -617,6 +617,46 @@ static blk_status_t scsi_result_to_blk_status(struct scsi_cmnd *cmd, int result)
}
}
+/**
+ * scsi_rq_err_bytes - determine number of bytes till the next failure boundary
+ * @rq: request to examine
+ *
+ * Description:
+ * A request could be merge of IOs which require different failure
+ * handling. This function determines the number of bytes which
+ * can be failed from the beginning of the request without
+ * crossing into area which need to be retried further.
+ *
+ * Return:
+ * The number of bytes to fail.
+ */
+static unsigned int scsi_rq_err_bytes(const struct request *rq)
+{
+ unsigned int ff = rq->cmd_flags & REQ_FAILFAST_MASK;
+ unsigned int bytes = 0;
+ struct bio *bio;
+
+ if (!(rq->rq_flags & RQF_MIXED_MERGE))
+ return blk_rq_bytes(rq);
+
+ /*
+ * Currently the only 'mixing' which can happen is between
+ * different fastfail types. We can safely fail portions
+ * which have all the failfast bits that the first one has -
+ * the ones which are at least as eager to fail as the first
+ * one.
+ */
+ for (bio = rq->bio; bio; bio = bio->bi_next) {
+ if ((bio->bi_opf & ff) != ff)
+ break;
+ bytes += bio->bi_iter.bi_size;
+ }
+
+ /* this could lead to infinite loop */
+ BUG_ON(blk_rq_bytes(rq) && !bytes);
+ return bytes;
+}
+
/* Helper for scsi_io_completion() when "reprep" action required. */
static void scsi_io_completion_reprep(struct scsi_cmnd *cmd,
struct request_queue *q)
@@ -794,7 +834,7 @@ static void scsi_io_completion_action(struct scsi_cmnd *cmd, int result)
scsi_print_command(cmd);
}
}
- if (!scsi_end_request(req, blk_stat, blk_rq_err_bytes(req)))
+ if (!scsi_end_request(req, blk_stat, scsi_rq_err_bytes(req)))
return;
fallthrough;
case ACTION_REPREP:
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index ebc45cf0450b3..9f9634cd4cfd2 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -949,7 +949,6 @@ struct req_iterator {
* blk_rq_pos() : the current sector
* blk_rq_bytes() : bytes left in the entire request
* blk_rq_cur_bytes() : bytes left in the current segment
- * blk_rq_err_bytes() : bytes left till the next error boundary
* blk_rq_sectors() : sectors left in the entire request
* blk_rq_cur_sectors() : sectors left in the current segment
* blk_rq_stats_sectors() : sectors of the entire request used for stats
@@ -973,8 +972,6 @@ static inline int blk_rq_cur_bytes(const struct request *rq)
return bio_iovec(rq->bio).bv_len;
}
-unsigned int blk_rq_err_bytes(const struct request *rq);
-
static inline unsigned int blk_rq_sectors(const struct request *rq)
{
return blk_rq_bytes(rq) >> SECTOR_SHIFT;
--
2.30.2
next prev parent reply other threads:[~2021-10-25 7:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 7:05 move all struct request releated code out of blk-core.c Christoph Hellwig
2021-10-25 7:05 ` Christoph Hellwig [this message]
2021-10-26 23:55 ` [PATCH 01/12] block: move blk_rq_err_bytes to scsi Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 02/12] block: remove blk_{get,put}_request Christoph Hellwig
2021-10-26 23:56 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 03/12] block: remove rq_flush_dcache_pages Christoph Hellwig
2021-10-25 7:05 ` [PATCH 04/12] block: remove blk-exec.c Christoph Hellwig
2021-10-26 23:58 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 05/12] blk-mq: move blk_mq_flush_plug_list Christoph Hellwig
2021-10-27 0:00 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 06/12] block: move request based cloning helpers to blk-mq.c Christoph Hellwig
2021-10-27 0:01 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 07/12] block: move blk_rq_init " Christoph Hellwig
2021-10-27 0:01 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 08/12] block: move blk_steal_bios " Christoph Hellwig
2021-10-27 0:02 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 09/12] block: move blk_account_io_{start,done} " Christoph Hellwig
2021-10-27 0:04 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 10/12] block: move blk_dump_rq_flags " Christoph Hellwig
2021-10-27 0:04 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 11/12] block: move blk_print_req_error " Christoph Hellwig
2021-10-27 0:06 ` Chaitanya Kulkarni
2021-10-25 7:05 ` [PATCH 12/12] block: don't include blk-mq headers in blk-core.c Christoph Hellwig
2021-10-27 0:07 ` Chaitanya Kulkarni
2021-10-29 12:52 ` (subset) move all struct request releated code out of blk-core.c Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211025070517.1548584-2-hch@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).