All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Josef Bacik <jbacik@fb.com>
Cc: linux-btrfs@vger.kernel.org
Subject: re: Btrfs: add support for multiple csum algorithms
Date: Mon, 25 Jan 2016 13:31:34 +0300	[thread overview]
Message-ID: <20160125103134.GA28950@mwanda> (raw)


Hello Josef Bacik,

The patch 607d432da054: "Btrfs: add support for multiple csum
algorithms" from Dec 2, 2008, leads to the following static checker
warning:

	fs/btrfs/disk-io.c:320 csum_tree_block()
	error: __memcpy() '&found' too small (4 vs 9)

fs/btrfs/disk-io.c
   278  static int csum_tree_block(struct btrfs_fs_info *fs_info,
   279                             struct extent_buffer *buf,
   280                             int verify)
   281  {
   282          u16 csum_size = btrfs_super_csum_size(fs_info->super_copy);

The problem here is that we wrote some incomplete stub code 8 years ago
an never used it.  Can we delete this stuff?

btrfs_super_csum_type() always returns 0 and thus
btrfs_super_csum_size() always returns 4.  There is a
btrfs_set_super_csum_type() function but it is never called otherwise
we would hit several bugs.

   283          char *result = NULL;
   284          unsigned long len;
   285          unsigned long cur_len;
   286          unsigned long offset = BTRFS_CSUM_SIZE;
   287          char *kaddr;
   288          unsigned long map_start;
   289          unsigned long map_len;
   290          int err;
   291          u32 crc = ~(u32)0;
   292          unsigned long inline_result;

Let's assume this is 64 bit system and inline_result is 8 bytes.

   293  
   294          len = buf->len - offset;
   295          while (len > 0) {
   296                  err = map_private_extent_buffer(buf, offset, 32,
   297                                          &kaddr, &map_start, &map_len);
   298                  if (err)
   299                          return 1;
   300                  cur_len = min(len, map_len - (offset - map_start));
   301                  crc = btrfs_csum_data(kaddr + offset - map_start,
   302                                        crc, cur_len);
   303                  len -= cur_len;
   304                  offset += cur_len;
   305          }
   306          if (csum_size > sizeof(inline_result)) {
   307                  result = kzalloc(csum_size, GFP_NOFS);

In the future code we would allocate 9+ bytes.

   308                  if (!result)
   309                          return 1;
   310          } else {
   311                  result = (char *)&inline_result;
   312          }
   313  
   314          btrfs_csum_final(crc, result);

We only ever use the first 4 bytes.  We need to add a size option to
this function to support future code.

   315  
   316          if (verify) {
   317                  if (memcmp_extent_buffer(buf, result, 0, csum_size)) {
   318                          u32 val;
   319                          u32 found = 0;
   320                          memcpy(&found, result, csum_size);

If csum_size were more than 4 this would corrupt memory.

   321  
   322                          read_extent_buffer(buf, &val, 0, csum_size);
   323                          btrfs_warn_rl(fs_info,
   324                                  "%s checksum verify failed on %llu wanted %X found %X "
   325                                  "level %d",
   326                                  fs_info->sb->s_id, buf->start,
   327                                  val, found, btrfs_header_level(buf));
   328                          if (result != (char *)&inline_result)
   329                                  kfree(result);
   330                          return 1;
   331                  }
   332          } else {
   333                  write_extent_buffer(buf, result, 0, csum_size);
   334          }
   335          if (result != (char *)&inline_result)
   336                  kfree(result);
   337          return 0;

regards,
dan carpenter

             reply	other threads:[~2016-01-26 16:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-25 10:31 Dan Carpenter [this message]
2016-01-26 21:22 ` Btrfs: add support for multiple csum algorithms Liu Bo
  -- strict thread matches above, loose matches on Subject: below --
2012-06-15 19:49 Dan Carpenter
2012-12-11 20:31 ` Dan Carpenter

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=20160125103134.GA28950@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.