Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@dilger.ca>
To: Wen Yang <wenyang@linux.alibaba.com>
Cc: riteshh@linux.ibm.com, tytso@mit.edu, linux-ext4@vger.kernel.org,
	jack@suse.cz, linux-kernel@vger.kernel.org,
	baoyou.xie@alibaba-inc.com
Subject: Re: [PATCH] ext4: add a configurable parameter to prevent endless loop in ext4_mb_discard_group_p
Date: Thu, 8 Apr 2021 16:11:35 -0600	[thread overview]
Message-ID: <F46B045A-D207-409A-ACD0-956851B46D6D@dilger.ca> (raw)
In-Reply-To: <f16d7afa-3799-f523-3c19-9ceb9427ff6e@linux.alibaba.com>

[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]

On Apr 8, 2021, at 12:50 PM, Wen Yang <wenyang@linux.alibaba.com> wrote:
> 
> Hi Ritesh and Andreas,
> 
> Thank you for your reply. Since there is still a faulty machine, we have analyzed it again and found it is indeed a very special case:
> 
> 
> crash> struct ext4_group_info ffff8813bb5f72d0
> struct ext4_group_info {
>  bb_state = 0,
>  bb_free_root = {
>    rb_node = 0x0
>  },
>  bb_first_free = 1681,
>  bb_free = 0,
>  bb_fragments = 0,
>  bb_largest_free_order = -1,
>  bb_prealloc_list = {
>    next = 0xffff880268291d78,
>    prev = 0xffff880268291d78     ---> *** The list is empty
>  },
>  alloc_sem = {
>    count = {
>      counter = 0
>    },
>    wait_list = {
>      next = 0xffff8813bb5f7308,
>      prev = 0xffff8813bb5f7308
>    },
>    wait_lock = {
>      raw_lock = {
>        {
>          val = {
>            counter = 0
>          },
>          {
>            locked = 0 '\000',
>            pending = 0 '\000'
>          },
>          {
>            locked_pending = 0,
>            tail = 0
>          }
>        }
>      }
>    },
>    osq = {
>      tail = {
>        counter = 0
>      }
>    },
>    owner = 0x0
>  },
>  bb_counters = 0xffff8813bb5f7328
> }
> crash>
> 
> 
> crash> list 0xffff880268291d78  -l ext4_prealloc_space.pa_group_list -s ext4_prealloc_space.pa_count
> ffff880268291d78
>  pa_count = {
>    counter = 1      ---> ****pa->pa_count
>  }
> ffff8813bb5f72f0
>  pa_count = {
>    counter = -30701
>  }
> 
> 
> crash> struct -xo  ext4_prealloc_space
> struct ext4_prealloc_space {
>   [0x0] struct list_head pa_inode_list;
>  [0x10] struct list_head pa_group_list;
>         union {
>             struct list_head pa_tmp_list;
>             struct callback_head pa_rcu;
>  [0x20] } u;
>  [0x30] spinlock_t pa_lock;
>  [0x34] atomic_t pa_count;
>  [0x38] unsigned int pa_deleted;
>  [0x40] ext4_fsblk_t pa_pstart;
>  [0x48] ext4_lblk_t pa_lstart;
>  [0x4c] ext4_grpblk_t pa_len;
>  [0x50] ext4_grpblk_t pa_free;
>  [0x54] unsigned short pa_type;
>  [0x58] spinlock_t *pa_obj_lock;
>  [0x60] struct inode *pa_inode;
> }
> SIZE: 0x68
> 
> 
> Before "goto repeat", it is necessary to check whether grp->bb_prealloc_list is empty.  This patch may fix it.
> Please kindly give us your comments and suggestions.
> Thanks.

This patch definitely looks more reasonable than the previous one, but
I don't think it is correct?

It isn't clear how the system could get into this state, or stay there.

If bb_prealloc_list is empty, then "busy" should be 0, since busy = 1
is only set inside "list_for_each_entry_safe(bb_prealloc_list)", and
that implies the list is *not* empty?  The ext4_lock_group() is held
over this code, so the list should not be changing in this case, and
even if the list changed, it _should_ only affect the loop one time.

> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 99bf091..8082e2d 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -4290,7 +4290,7 @@ static void ext4_mb_new_preallocation(struct ext4_allocation_context *ac)
>        free_total += free;
> 
>        /* if we still need more blocks and some PAs were used, try again */
> -       if (free_total < needed && busy) {
> +       if (free_total < needed && busy && !list_empty(&grp->bb_prealloc_list)) {
>                ext4_unlock_group(sb, group);
>                cond_resched();
>                busy = 0;
>                goto repeat;

Minor suggestion - moving "busy = 0" right after "repeat:" and removing
the "int busy = 0" initializer would make this code a bit more clear.

Cheers, Andreas




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

  reply	other threads:[~2021-04-08 22:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 18:50 [PATCH] ext4: add a configurable parameter to prevent endless loop in ext4_mb_discard_group_p Wen Yang
2021-04-08 22:11 ` Andreas Dilger [this message]
2021-04-09  5:47 ` riteshh
2021-04-09 10:18   ` Jan Kara
2021-04-09 11:28     ` riteshh
2021-04-10 19:45   ` Wen Yang
2021-04-11  4:25     ` Theodore Ts'o
2021-04-15  7:53       ` Wen Yang

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=F46B045A-D207-409A-ACD0-956851B46D6D@dilger.ca \
    --to=adilger@dilger.ca \
    --cc=baoyou.xie@alibaba-inc.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riteshh@linux.ibm.com \
    --cc=tytso@mit.edu \
    --cc=wenyang@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox