linux-kernel - Re: [GIT PULL] Btrfs fixes for 5.5-rc5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL3q7H4ZVTdd093hiEnYUusEvgoiLPaCaF2=f-y8i6oZQ0hqhQ@mail.gmail.com>
Date:   Sat, 4 Jan 2020 12:32:00 +0000
From:   Filipe Manana <fdmanana@...il.com>
To:     David Sterba <dsterba@...e.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Btrfs fixes for 5.5-rc5

On Fri, Jan 3, 2020 at 5:44 PM David Sterba <dsterba@...e.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 fbd542971aa1e9ec33212afe1d9b4f1106cd85a1:
>
>   btrfs: send: remove WARN_ON for readonly mount (2019-12-13 14:10:46 +0100)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.5-rc4-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(-)



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”