All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: <fdmanana@gmail.com>
Cc: "dsterba@suse.cz" <dsterba@suse.cz>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v3 RESENT 2/2] btrfs: qgroup: Don't copy extent buffer to do qgroup rescan
Date: Thu, 22 Oct 2015 16:45:23 +0800	[thread overview]
Message-ID: <5628A223.3030901@cn.fujitsu.com> (raw)
In-Reply-To: <CAL3q7H5DNTCBAjqhFhxMnRTnUmmU=skzWqLcm9GB49zvN68BMg@mail.gmail.com>



Filipe Manana wrote on 2015/10/22 09:16 +0100:
> On Thu, Oct 22, 2015 at 1:42 AM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>> Ancient qgroup code call memcpy() on a extent buffer and use it for leaf
>> iteration.
>>
>> As extent buffer contains lock, pointers to pages, it's never sane to do
>> such copy.
>>
>> The following bug may be caused by this insane operation:
>> [92098.841309] general protection fault: 0000 [#1] SMP
>> [92098.841338] Modules linked in: ...
>> [92098.841814] CPU: 1 PID: 24655 Comm: kworker/u4:12 Not tainted
>> 4.3.0-rc1 #1
>> [92098.841868] Workqueue: btrfs-qgroup-rescan btrfs_qgroup_rescan_helper
>> [btrfs]
>> [92098.842261] Call Trace:
>> [92098.842277]  [<ffffffffc035a5d8>] ? read_extent_buffer+0xb8/0x110
>> [btrfs]
>> [92098.842304]  [<ffffffffc0396d00>] ? btrfs_find_all_roots+0x60/0x70
>> [btrfs]
>> [92098.842329]  [<ffffffffc039af3d>]
>> btrfs_qgroup_rescan_worker+0x28d/0x5a0 [btrfs]
>>
>> Where btrfs_qgroup_rescan_worker+0x28d is btrfs_disk_key_to_cpu(),
>> called in reading key from the memcpied extent_buffer.
>>
>> This patch will read the whole leaf into memory, and use newly
>> introduced stack function to do qgroup rescan.
>
> Hi Qu,
>
> Instead of introducing more new functions, why not clone the extent
> buffer (btrfs_clone_extent_buffer) and then use it the
> regular/existing functions? Iow, the same as we do in backref walking,
> should make the change much smaller than it is.
>
> thanks
>
Thanks Filipe,

I didn't know there is such a nice function.
And it's setting EXTENT_BUFFER_DUMMY, so it should be quite safe for the 
use case.

Thanks for your advice a lot!
Qu

>>
>> Reported-by: Stephane Lesimple <stephane_btrfs@lesimple.fr>
>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>> ---
>> v2:
>>    Follow the parameter change in previous patch.
>> v3:
>>    None
>> ---
>>   fs/btrfs/qgroup.c | 22 ++++++++++++----------
>>   1 file changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
>> index e9ace09..6a83a40 100644
>> --- a/fs/btrfs/qgroup.c
>> +++ b/fs/btrfs/qgroup.c
>> @@ -2183,11 +2183,11 @@ void assert_qgroups_uptodate(struct btrfs_trans_handle *trans)
>>    */
>>   static int
>>   qgroup_rescan_leaf(struct btrfs_fs_info *fs_info, struct btrfs_path *path,
>> -                  struct btrfs_trans_handle *trans,
>> -                  struct extent_buffer *scratch_leaf)
>> +                  struct btrfs_trans_handle *trans, char *stack_leaf)
>>   {
>>          struct btrfs_key found;
>>          struct ulist *roots = NULL;
>> +       struct btrfs_header *header;
>>          struct seq_list tree_mod_seq_elem = SEQ_LIST_INIT(tree_mod_seq_elem);
>>          u64 num_bytes;
>>          int slot;
>> @@ -2224,13 +2224,15 @@ qgroup_rescan_leaf(struct btrfs_fs_info *fs_info, struct btrfs_path *path,
>>          fs_info->qgroup_rescan_progress.objectid = found.objectid + 1;
>>
>>          btrfs_get_tree_mod_seq(fs_info, &tree_mod_seq_elem);
>> -       memcpy(scratch_leaf, path->nodes[0], sizeof(*scratch_leaf));
>> +       read_extent_buffer(path->nodes[0], stack_leaf, 0,
>> +                          fs_info->extent_root->nodesize);
>> +       header = (struct btrfs_header *)stack_leaf;
>>          slot = path->slots[0];
>>          btrfs_release_path(path);
>>          mutex_unlock(&fs_info->qgroup_rescan_lock);
>>
>> -       for (; slot < btrfs_header_nritems(scratch_leaf); ++slot) {
>> -               btrfs_item_key_to_cpu(scratch_leaf, &found, slot);
>> +       for (; slot < btrfs_stack_header_nritems(header); ++slot) {
>> +               btrfs_stack_item_key_to_cpu(header, &found, slot);
>>                  if (found.type != BTRFS_EXTENT_ITEM_KEY &&
>>                      found.type != BTRFS_METADATA_ITEM_KEY)
>>                          continue;
>> @@ -2261,15 +2263,15 @@ static void btrfs_qgroup_rescan_worker(struct btrfs_work *work)
>>                                                       qgroup_rescan_work);
>>          struct btrfs_path *path;
>>          struct btrfs_trans_handle *trans = NULL;
>> -       struct extent_buffer *scratch_leaf = NULL;
>> +       char *stack_leaf = NULL;
>>          int err = -ENOMEM;
>>          int ret = 0;
>>
>>          path = btrfs_alloc_path();
>>          if (!path)
>>                  goto out;
>> -       scratch_leaf = kmalloc(sizeof(*scratch_leaf), GFP_NOFS);
>> -       if (!scratch_leaf)
>> +       stack_leaf = kmalloc(fs_info->extent_root->nodesize, GFP_NOFS);
>> +       if (!stack_leaf)
>>                  goto out;
>>
>>          err = 0;
>> @@ -2283,7 +2285,7 @@ static void btrfs_qgroup_rescan_worker(struct btrfs_work *work)
>>                          err = -EINTR;
>>                  } else {
>>                          err = qgroup_rescan_leaf(fs_info, path, trans,
>> -                                                scratch_leaf);
>> +                                                stack_leaf);
>>                  }
>>                  if (err > 0)
>>                          btrfs_commit_transaction(trans, fs_info->fs_root);
>> @@ -2292,7 +2294,7 @@ static void btrfs_qgroup_rescan_worker(struct btrfs_work *work)
>>          }
>>
>>   out:
>> -       kfree(scratch_leaf);
>> +       kfree(stack_leaf);
>>          btrfs_free_path(path);
>>
>>          mutex_lock(&fs_info->qgroup_rescan_lock);
>> --
>> 2.6.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

      reply	other threads:[~2015-10-22  8:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22  0:42 [PATCH v3 RESENT 1/2] btrfs: Add support to do stack item key operation Qu Wenruo
2015-10-22  0:42 ` [PATCH v3 RESENT 2/2] btrfs: qgroup: Don't copy extent buffer to do qgroup rescan Qu Wenruo
2015-10-22  8:16   ` Filipe Manana
2015-10-22  8:45     ` Qu Wenruo [this message]

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=5628A223.3030901@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=dsterba@suse.cz \
    --cc=fdmanana@gmail.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.