Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <cover.1578072747.git.dsterba@suse.com>
In-Reply-To: <cover.1578072747.git.dsterba@suse.com>
Reply-To: fdmanana@gmail.com
From:   Filipe Manana <fdmanana@gmail.com>
Date:   Sat, 4 Jan 2020 12:32:00 +0000
Message-ID: <CAL3q7H4ZVTdd093hiEnYUusEvgoiLPaCaF2=f-y8i6oZQ0hqhQ@mail.gmail.com>
Subject: Re: [GIT PULL] Btrfs fixes for 5.5-rc5
To:     David Sterba <dsterba@suse.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        linux-btrfs <linux-btrfs@vger.kernel.org>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jan 3, 2020 at 5:44 PM David Sterba <dsterba@suse.com> wrote:
>
> Hi,
>
> a few fixes for btrfs:
>
> * blkcg accounting problem with compression that could stall writes
>
> * setting up blkcg bio for compression crashes due to NULL bdev pointer
>
> * fix possible infinite loop in writeback for nocow files (here possible
>   means almost impossible, 13 things that need to happen to trigger it)

Some corrections regarding this last bullet point.

The issue is not about nocow files. It's about writes into
preallocated extents (allocated through plain fallocate() or
fallocate's zero range),
which triggers nocow writeback.

Secondly, the "13 things that need to happen to trigger it" is confusing.
The changelog has 13 bullet points that describe the race that
triggers the problem, they are not steps that need to happen.
The conditions necessary to trigger it are far less than 13.

The first paragraph of the changelog summarizes when the problem can happen=
:

"When starting writeback for a range that covers part of a preallocated
extent, due to a race with writeback for another range that also covers
another part of the same preallocated extent, we can end up in an infinite
loop."

And the issue is far from almost impossible or theoretical.
Long runs of fsx (1 million operations or more), such as the one from
the test case generic/522 from fstests, can trigger it sporadically (I
could trigger it a few times per week).

Thanks.


>
> Please pull, thanks.
>
> ----------------------------------------------------------------
> The following changes since commit fbd542971aa1e9ec33212afe1d9b4f1106cd85=
a1:
>
>   btrfs: send: remove WARN_ON for readonly mount (2019-12-13 14:10:46 +01=
00)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.5-r=
c4-tag
>
> for you to fetch changes up to de7999afedff02c6631feab3ea726a0e8f8c3d40:
>
>   Btrfs: fix infinite loop during nocow writeback due to race (2019-12-30=
 16:13:20 +0100)
>
> ----------------------------------------------------------------
> Dennis Zhou (2):
>       btrfs: punt all bios created in btrfs_submit_compressed_write()
>       btrfs: fix compressed write bio blkcg attribution
>
> Filipe Manana (1):
>       Btrfs: fix infinite loop during nocow writeback due to race
>
>  fs/btrfs/compression.c | 7 ++++++-
>  fs/btrfs/inode.c       | 6 +++---
>  2 files changed, 9 insertions(+), 4 deletions(-)


--=20
Filipe David Manana,

=E2=80=9CWhether you think you can, or you think you can't =E2=80=94 you're=
 right.=E2=80=9D