All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: quwenruo@cn.fujitsu.com
Cc: linux-btrfs@vger.kernel.org
Subject: [bug report] btrfs: Expoert and move leaf/subtree qgroup helpers to qgroup.c
Date: Thu, 10 Nov 2016 23:18:26 +0300	[thread overview]
Message-ID: <20161110201826.GA29230@mwanda> (raw)

Hello Qu Wenruo,

The patch 4c98cc4b6d12: "btrfs: Expoert and move leaf/subtree qgroup
helpers to qgroup.c" from Oct 18, 2016, leads to the following static
checker warning:

	fs/btrfs/qgroup.c:1682 btrfs_qgroup_trace_subtree()
	error: buffer overflow 'path->nodes' 8 <= 8

fs/btrfs/qgroup.c
  1641  int btrfs_qgroup_trace_subtree(struct btrfs_trans_handle *trans,
  1642                                 struct btrfs_root *root,
  1643                                 struct extent_buffer *root_eb,
  1644                                 u64 root_gen, int root_level)
  1645  {
  1646          int ret = 0;
  1647          int level;
  1648          struct extent_buffer *eb = root_eb;
  1649          struct btrfs_path *path = NULL;
  1650  
  1651          BUG_ON(root_level < 0 || root_level > BTRFS_MAX_LEVEL);

You didn't really introduce the warning, just made it show up as a new
warning by moving the code around.  Still, this should be
>= BTRFS_MAX_LEVEL shouldn't it?


  1652          BUG_ON(root_eb == NULL);
  1653  
  1654          if (!test_bit(BTRFS_FS_QUOTA_ENABLED, &root->fs_info->flags))
  1655                  return 0;
  1656  
  1657          if (!extent_buffer_uptodate(root_eb)) {
  1658                  ret = btrfs_read_buffer(root_eb, root_gen);
  1659                  if (ret)
  1660                          goto out;
  1661          }
  1662  
  1663          if (root_level == 0) {
  1664                  ret = btrfs_qgroup_trace_leaf_items(trans, root, root_eb);
  1665                  goto out;
  1666          }
  1667  
  1668          path = btrfs_alloc_path();
  1669          if (!path)
  1670                  return -ENOMEM;
  1671  
  1672          /*
  1673           * Walk down the tree.  Missing extent blocks are filled in as
  1674           * we go. Metadata is accounted every time we read a new
  1675           * extent block.
  1676           *
  1677           * When we reach a leaf, we account for file extent items in it,
  1678           * walk back up the tree (adjusting slot pointers as we go)
  1679           * and restart the search process.
  1680           */
  1681          extent_buffer_get(root_eb); /* For path */
  1682          path->nodes[root_level] = root_eb;

Otherwise, we're off by one.

  1683          path->slots[root_level] = 0;
  1684          path->locks[root_level] = 0; /* so release_path doesn't try to unlock */
  1685  walk_down:

regards,
dan carpenter

                 reply	other threads:[~2016-11-10 20:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20161110201826.GA29230@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.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.