On Fri, Mar 11, 2022 at 02:08:37PM +0000, Filipe Manana wrote:
> On Fri, Mar 11, 2022 at 04:38:02PM +0900, Naohiro Aota wrote:
> > When btrfs balance is interrupted with umount, the background balance
> > resumes on the next mount. There is a potential deadlock with FS freezing
> > here like as described in commit 26559780b953 ("btrfs: zoned: mark
> > relocation as writing").
> >
> > Mark the process as sb_writing. To preserve the order of sb_start_write()
> > (or mnt_want_write_file()) and btrfs_exclop_start(), call sb_start_write()
> > at btrfs_resume_balance_async() before taking fs_info->super_lock.
> >
> > Fixes: 5accdf82ba25 ("fs: Improve filesystem freezing handling")
>
> This seems odd to me. I read the note you left on the cover letter about
> this, but honestly I don't think it's fair to blame that commit. I see
> it more as btrfs specific problem.
Yeah, I was really not sure how I should write the tag. The issue is
we missed to add sb_start_write() after this commit.
> Plus it's a 10 years old commit, so instead of the Fixes tag, adding a
> minimal kernel version to the CC stable tag below makes more sense.
So, only with "Cc: stable@xxxxxxxxxxxxxxx # 3.6+" ?
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: Naohiro Aota <naohiro.aota@xxxxxxx>
> > ---
> > fs/btrfs/volumes.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> > index 1be7cb2f955f..0d27d8d35c7a 100644
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -4443,6 +4443,7 @@ static int balance_kthread(void *data)
> > if (fs_info->balance_ctl)
> > ret = btrfs_balance(fs_info, fs_info->balance_ctl, NULL);
> > mutex_unlock(&fs_info->balance_mutex);
> > + sb_end_write(fs_info->sb);
> >
> > return ret;
> > }
> > @@ -4463,6 +4464,7 @@ int btrfs_resume_balance_async(struct btrfs_fs_info *fs_info)
> > return 0;
> > }
> >
> > + sb_start_write(fs_info->sb);
>
> I don't understand this.
>
> We are doing the sb_start_write() here, in the task doing the mount, and then
> we do the sb_end_write() at the kthread that runs balance_kthread().
Oops, I made a mistake here. It actually printed the lockdep warning
"lock held when returning to user space!".
> Why not do the sb_start_write() in the kthread?
>
> This is also buggy in the case the call below to kthread_run() fails, as
> we end up never calling sb_end_write().
I was trying to preserve the lock taking order: sb_start_write() ->
spin_lock(fs_info->super_lock). But, it might not be a big deal as
long as we don't call sb_start_write() in the super_lock.
> Thanks.
>
> > spin_lock(&fs_info->super_lock);
> > ASSERT(fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED);
> > fs_info->exclusive_operation = BTRFS_EXCLOP_BALANCE;
> > --
> > 2.35.1
> >
