From: Dan Mick <dan.mick@inktank.com>
To: Alex Elder <elder@inktank.com>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH REPOST] rbd: be picky about osd request status type
Date: Fri, 04 Jan 2013 21:07:01 -0800 [thread overview]
Message-ID: <50E7B4F5.7010800@inktank.com> (raw)
In-Reply-To: <50E608F0.3010501@inktank.com>
I personally dislike "spaces after cast", but I haven't checked the
kernel style guide. Otherwise:
Reviewed-by: Dan Mick <dan.mick@inktank.com>
On 01/03/2013 02:40 PM, Alex Elder wrote:
> The result field in a ceph osd reply header is a signed 32-bit type,
> but rbd code often casually uses int to represent it.
>
> The following changes the types of variables that handle this result
> value to be "s32" instead of "int" to be completely explicit about
> it. Only at the point we pass that result to __blk_end_request()
> does the type get converted to the plain old int defined for that
> interface.
>
> There is almost certainly no binary impact of this change, but I
> prefer to show the exact size and signedness of the value since we
> know it.
>
> Signed-off-by: Alex Elder <elder@inktank.com>
> ---
> drivers/block/rbd.c | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> index 85131de..8b79a5b 100644
> --- a/drivers/block/rbd.c
> +++ b/drivers/block/rbd.c
> @@ -171,7 +171,7 @@ struct rbd_client {
> */
> struct rbd_req_status {
> int done;
> - int rc;
> + s32 rc;
> u64 bytes;
> };
>
> @@ -1053,13 +1053,13 @@ static void rbd_destroy_ops(struct
> ceph_osd_req_op *ops)
> static void rbd_coll_end_req_index(struct request *rq,
> struct rbd_req_coll *coll,
> int index,
> - int ret, u64 len)
> + s32 ret, u64 len)
> {
> struct request_queue *q;
> int min, max, i;
>
> dout("rbd_coll_end_req_index %p index %d ret %d len %llu\n",
> - coll, index, ret, (unsigned long long) len);
> + coll, index, (int) ret, (unsigned long long) len);
>
> if (!rq)
> return;
> @@ -1080,7 +1080,7 @@ static void rbd_coll_end_req_index(struct request *rq,
> max++;
>
> for (i = min; i<max; i++) {
> - __blk_end_request(rq, coll->status[i].rc,
> + __blk_end_request(rq, (int) coll->status[i].rc,
> coll->status[i].bytes);
> coll->num_done++;
> kref_put(&coll->kref, rbd_coll_release);
> @@ -1089,7 +1089,7 @@ static void rbd_coll_end_req_index(struct request *rq,
> }
>
> static void rbd_coll_end_req(struct rbd_request *rbd_req,
> - int ret, u64 len)
> + s32 ret, u64 len)
> {
> rbd_coll_end_req_index(rbd_req->rq,
> rbd_req->coll, rbd_req->coll_index,
> @@ -1129,7 +1129,7 @@ static int rbd_do_request(struct request *rq,
> if (!rbd_req) {
> if (coll)
> rbd_coll_end_req_index(rq, coll, coll_index,
> - -ENOMEM, len);
> + (s32) -ENOMEM, len);
> return -ENOMEM;
> }
>
> @@ -1206,7 +1206,7 @@ done_err:
> bio_chain_put(rbd_req->bio);
> ceph_osdc_put_request(osd_req);
> done_pages:
> - rbd_coll_end_req(rbd_req, ret, len);
> + rbd_coll_end_req(rbd_req, (s32) ret, len);
> kfree(rbd_req);
> return ret;
> }
> @@ -1219,7 +1219,7 @@ static void rbd_req_cb(struct ceph_osd_request
> *osd_req, struct ceph_msg *msg)
> struct rbd_request *rbd_req = osd_req->r_priv;
> struct ceph_osd_reply_head *replyhead;
> struct ceph_osd_op *op;
> - __s32 rc;
> + s32 rc;
> u64 bytes;
> int read_op;
>
> @@ -1227,14 +1227,14 @@ static void rbd_req_cb(struct ceph_osd_request
> *osd_req, struct ceph_msg *msg)
> replyhead = msg->front.iov_base;
> WARN_ON(le32_to_cpu(replyhead->num_ops) == 0);
> op = (void *)(replyhead + 1);
> - rc = le32_to_cpu(replyhead->result);
> + rc = (s32) le32_to_cpu(replyhead->result);
> bytes = le64_to_cpu(op->extent.length);
> read_op = (le16_to_cpu(op->op) == CEPH_OSD_OP_READ);
>
> dout("rbd_req_cb bytes=%llu readop=%d rc=%d\n",
> (unsigned long long) bytes, read_op, (int) rc);
>
> - if (rc == -ENOENT && read_op) {
> + if (rc == (s32) -ENOENT && read_op) {
> zero_bio_chain(rbd_req->bio, 0);
> rc = 0;
> } else if (rc == 0 && read_op && bytes < rbd_req->len) {
> @@ -1679,7 +1679,8 @@ static void rbd_rq_fn(struct request_queue *q)
> bio_chain, coll, cur_seg);
> else
> rbd_coll_end_req_index(rq, coll, cur_seg,
> - -ENOMEM, chain_size);
> + (s32) -ENOMEM,
> + chain_size);
> size -= chain_size;
> ofs += chain_size;
>
next prev parent reply other threads:[~2013-01-05 5:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-03 22:40 [PATCH REPOST] rbd: be picky about osd request status type Alex Elder
2013-01-05 5:07 ` Dan Mick [this message]
2013-01-05 18:33 ` Alex Elder
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=50E7B4F5.7010800@inktank.com \
--to=dan.mick@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=elder@inktank.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