[ 90/95] rbd: use the correct length for format 2 object names

[Greg Kroah-Hartman]

3.9-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Josh Durgin <josh.durgin@xxxxxxxxxxx>

commit 3a96d5cd7bdce45d5dded75c3a62d4fb98050280 upstream.

[Backported for 3.9-stable.
'kmalloc(MAX_OBJ_NAME_SIZE + 1, GFP_NOIO)' was changed as
'kmem_cache_alloc(rbd_segment_name_cache, GFP_NOIO)' in 78c2a44
since 3.10-rc1, and 78c2a44 is relied on a big patchset, so restore
it as 3.9 did.]

Format 2 objects use 16 characters for the object name suffix to be
able to express the full 64-bit range of object numbers. Format 1
images only use 12 characters for this. Using 12-character names for
format 2 caused userspace and kernel rbd clients to read differently
named objects, which made an image written by one client look empty to
the other client.

Reported-by: Chris Dunlop <chris@xxxxxxxxxxxx>
Signed-off-by: Josh Durgin <josh.durgin@xxxxxxxxxxx>
Reviewed-by: Sage Weil <sage@xxxxxxxxxxx>
Reviewed-by: Lingzhu Xiang <lxiang@xxxxxxxxxx>
Signed-off-by: Zhouping Liu <zliu@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
 drivers/block/rbd.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -833,12 +833,16 @@ static const char *rbd_segment_name(stru
 	char *name;
 	u64 segment;
 	int ret;
+	char *name_format;
 
 	name = kmalloc(MAX_OBJ_NAME_SIZE + 1, GFP_NOIO);
 	if (!name)
 		return NULL;
 	segment = offset >> rbd_dev->header.obj_order;
-	ret = snprintf(name, MAX_OBJ_NAME_SIZE + 1, "%s.%012llx",
+	name_format = "%s.%012llx";
+	if (rbd_dev->image_format == 2)
+		name_format = "%s.%016llx";
+	ret = snprintf(name, MAX_OBJ_NAME_SIZE + 1, name_format,
 			rbd_dev->header.object_prefix, segment);
 	if (ret < 0 || ret > MAX_OBJ_NAME_SIZE) {
 		pr_err("error formatting segment name for #%llu (%d)\n",


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/