btrfs-progs: fix len of read_extent_buffer for inline extent in restore
authorGui Hecheng <guihc.fnst@cn.fujitsu.com>
Thu, 28 Aug 2014 02:25:53 +0000 (10:25 +0800)
committerDavid Sterba <dsterba@suse.cz>
Sun, 14 Sep 2014 12:49:00 +0000 (14:49 +0200)
commitc7d16e08bdca950f615c4103dd1a4d8d7f810ab1
treec6794a9bdf1bdc6a2c25ff91697cc14f24f329ff
parent977f2baf363b59d4263d870b292975e2b791cd07
btrfs-progs: fix len of read_extent_buffer for inline extent in restore

Steps to reproduce:
# mkfs.btrfs -f <dev>
# mount -o compress-force=lzo <dev> <mnt>
# for ((i=0;i<4000;i++)); do
   echo -n 'A' >> <mnt>/inline_data
  done
# umount <mnt>
# valgrind --tool=memcheck --leak-check=full \
  btrfs restore <dev> <dest_dir>
output:
==32118== Invalid read of size 1
==32118==    at 0x4A0A4E4: memcpy@@GLIBC_2.14
==32118==    by 0x43DC91: read_extent_buffer
==32118==    by 0x421401: search_dir (cmds-restore.c:240)
==32118==    by 0x422CBB: cmd_restore (cmds-restore.c:1317)
==32118==    by 0x404709: main (btrfs.c:248)
==32118==  Address 0x4c4f4ac is not stack'd, malloc'd or...

It is because when deal with inline extent, the read_extent_buffer
is now reading a len of @ram_bytes which is the len of the uncompressed
data. But actually here we want the len of the inline item.
So in the compressed situation, use the len of the inline item.

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
cmds-restore.c