From: Alex Elder <elder@inktank.com>
To: Yehuda Sadeh <yehuda@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: [PATCH 03/11] rbd: kill incore snap_names_len
Date: Thu, 30 Aug 2012 11:41:55 -0500 [thread overview]
Message-ID: <503F97D3.7050004@inktank.com> (raw)
In-Reply-To: <CAC-hyiGmZwmnNdX=+y9BBsWuYRzXvu4Nah6pedn-_x4ZYLW3VQ@mail.gmail.com>
On 08/30/2012 11:24 AM, Yehuda Sadeh wrote:
> On Fri, Aug 24, 2012 at 9:33 AM, Alex Elder <elder@inktank.com> wrote:
>> The only thing the on-disk snap_names_len field is used for is to
>> size the buffer allocated to hold a copy of the snapshot names for
>> an rbd image.
>>
>> Don't bother saving it in the in-core rbd_image_header structure.
>> Just use a local variable to hold the required buffer size while
>> it's needed.
>>
>> Move the code that actually copies the snapshot names up closer
>> to where the required length is saved.
>>
>> Signed-off-by: Alex Elder <elder@inktank.com>
>> ---
>> drivers/block/rbd.c | 19 ++++++-------------
>> 1 file changed, 6 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
>> index a8a4cba..7b3d861 100644
>> --- a/drivers/block/rbd.c
>> +++ b/drivers/block/rbd.c
>> @@ -81,7 +81,6 @@ struct rbd_image_header {
>> __u8 crypt_type;
>> __u8 comp_type;
>> struct ceph_snap_context *snapc;
>> - u64 snap_names_len;
>> u32 total_snaps;
>>
>> char *snap_names;
>> @@ -534,12 +533,14 @@ static int rbd_header_from_disk(struct
>> rbd_image_header *header,
>> header->object_prefix[len] = '\0';
>>
>> if (snap_count) {
>> - header->snap_names_len = le64_to_cpu(ondisk->snap_names_len);
>> - BUG_ON(header->snap_names_len > (u64) SIZE_MAX);
>> - header->snap_names = kmalloc(header->snap_names_len,
>> - GFP_KERNEL);
>> + u64 snap_names_len = le64_to_cpu(ondisk->snap_names_len);
>> +
>> + BUG_ON(snap_names_len > (u64) SIZE_MAX);
>
> Should we get rid of this BUG_ON and return -EIO instead?
Yes. I've been using BUG_ON() a bit freely and I'd really like
to define a CEPH_ASSERT() or something instead. In this case I
can return an error value so I will.
I'll define CEPH_ASSERT() at some point, separately so I can
state assumptions without potentially killing the kernel.
>> + header->snap_names = kmalloc(snap_names_len, GFP_KERNEL);
>> if (!header->snap_names)
>> goto out_err;
>> + memcpy(header->snap_names, &ondisk->snaps[snap_count],
>> + snap_names_len);
>
> I think we're missing a check here to verify that we don't exceed the
> ondisk buffer
I believe in this case we're OK, though it's not obvious looking
only at this code. (I'm looking at code with all these patches
applied at the moment, so I may need to reorder the patches for the
following explanation to be valid.)
The ondisk buffer passed in here came from a successful call to
what's now called rbd_dev_v1_header_read(), which reads the
header in *only*, and only succeeds if it got everything it
was looking for--namely the snapshot context, plus the size
of the set of names that the context says will follow. It
will furthermore re-read the header if the count of snapshots
found in what got read differed from what we wanted it to be.
Therefore the ondisk header+names buffer here will always be
self-consistent--there will be room in the buffer for exactly
the number of bytes to hold the set of NUL-terminated snapshot
names.
If I could find an easy way to verify this here I would, but
right now the size of the ondisk buffer passed in is not
available. If you think it's important I can make changes
so it is though.
And in any case, before I commit anything I'll take another
look at this patch and maybe reorder things so the above
argument holds water.
-Alex
>>
>> size = snap_count * sizeof (*header->snap_sizes);
>> header->snap_sizes = kmalloc(size, GFP_KERNEL);
>> @@ -547,7 +548,6 @@ static int rbd_header_from_disk(struct
>> rbd_image_header *header,
>> goto out_err;
>> } else {
>> WARN_ON(ondisk->snap_names_len);
>> - header->snap_names_len = 0;
>> header->snap_names = NULL;
>> header->snap_sizes = NULL;
>> }
>> @@ -579,10 +579,6 @@ static int rbd_header_from_disk(struct
>> rbd_image_header *header,
>> header->snap_sizes[i] =
>> le64_to_cpu(ondisk->snaps[i].image_size);
>> }
>> -
>> - /* copy snapshot names */
>> - memcpy(header->snap_names, &ondisk->snaps[snap_count],
>> - header->snap_names_len);
>> }
>>
>> return 0;
>> @@ -592,7 +588,6 @@ out_err:
>> header->snap_sizes = NULL;
>> kfree(header->snap_names);
>> header->snap_names = NULL;
>> - header->snap_names_len = 0;
>> kfree(header->object_prefix);
>> header->object_prefix = NULL;
>>
>> @@ -660,7 +655,6 @@ static void rbd_header_free(struct rbd_image_header
>> *header)
>> header->snap_sizes = NULL;
>> kfree(header->snap_names);
>> header->snap_names = NULL;
>> - header->snap_names_len = 0;
>> ceph_put_snap_context(header->snapc);
>> header->snapc = NULL;
>> }
>> @@ -1800,7 +1794,6 @@ static int __rbd_refresh_header(struct rbd_device
>> *rbd_dev, u64 *hver)
>> rbd_dev->header.total_snaps = h.total_snaps;
>> rbd_dev->header.snapc = h.snapc;
>> rbd_dev->header.snap_names = h.snap_names;
>> - rbd_dev->header.snap_names_len = h.snap_names_len;
>> rbd_dev->header.snap_sizes = h.snap_sizes;
>> /* Free the extra copy of the object prefix */
>> WARN_ON(strcmp(rbd_dev->header.object_prefix, h.object_prefix));
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2012-08-30 16:41 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-24 16:26 [PATCH 00/11] rbd: another set of patches Alex Elder
2012-08-24 16:32 ` [PATCH 01/11] rbd: handle locking inside __rbd_client_find() Alex Elder
2012-08-30 16:09 ` Yehuda Sadeh
2012-08-24 16:32 ` [PATCH 02/11] rbd: don't over-allocate space for object prefix Alex Elder
2012-08-30 16:18 ` Yehuda Sadeh
2012-08-24 16:33 ` [PATCH 03/11] rbd: kill incore snap_names_len Alex Elder
2012-08-30 16:24 ` Yehuda Sadeh
2012-08-30 16:41 ` Alex Elder [this message]
2012-09-06 15:36 ` [PATCH, v2 " Alex Elder
2012-09-07 21:22 ` Yehuda Sadeh
2012-08-24 16:33 ` [PATCH 04/11] rbd: more cleanup in rbd_header_from_disk() Alex Elder
2012-08-30 16:48 ` Yehuda Sadeh
2012-08-24 16:33 ` [PATCH 05/11] rbd: move rbd_opts to struct rbd_device Alex Elder
2012-08-30 17:07 ` Yehuda Sadeh
2012-09-06 14:21 ` Alex Elder
2012-09-07 21:40 ` Yehuda Sadeh
2012-08-24 16:34 ` [PATCH 06/11] rbd: add read_only rbd map option Alex Elder
2012-08-30 17:29 ` Yehuda Sadeh
2012-08-30 17:39 ` Alex Elder
2012-09-06 15:36 ` [PATCH, v2 " Alex Elder
2012-09-07 15:45 ` Sage Weil
2012-09-07 20:36 ` Alex Elder
2012-09-07 21:26 ` Yehuda Sadeh Weinraub
2012-08-24 16:34 ` [PATCH 07/11] rbd: kill notify_timeout option Alex Elder
2012-08-30 17:31 ` Yehuda Sadeh
2012-08-24 16:35 ` [PATCH 08/11] rbd: bio_chain_clone() cleanups Alex Elder
2012-08-30 17:40 ` Yehuda Sadeh
2012-08-24 16:35 ` [PATCH 09/11] rbd: drop needless test in rbd_rq_fn() Alex Elder
2012-08-30 17:41 ` Yehuda Sadeh
2012-08-24 16:36 ` [PATCH 10/11] rbd: check for overflow in rbd_get_num_segments() Alex Elder
2012-08-30 17:50 ` Yehuda Sadeh
2012-08-24 16:36 ` [PATCH 11/11] rbd: split up rbd_get_segment() Alex Elder
2012-08-30 18:03 ` Yehuda Sadeh
2012-08-30 12:32 ` [PATCH 00/11] rbd: another set of patches Alex Elder
2012-09-06 15:34 ` 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=503F97D3.7050004@inktank.com \
--to=elder@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=yehuda@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.