linux-kernel - Re: [PATCH AUTOSEL 5.17 17/21] btrfs: reset last_reflink

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]

Date:   Thu, 31 Mar 2022 18:57:00 +0100
From:   Filipe Manana <fdmanana@...nel.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org, Filipe Manana <fdmanana@...e.com>,
        David Sterba <dsterba@...e.com>, Chris Mason <clm@...com>,
        Josef Bacik <jbacik@...com>,
        linux-btrfs <linux-btrfs@...r.kernel.org>
Subject: Re: [PATCH AUTOSEL 5.17 17/21] btrfs: reset last_reflink_trans after
 fsyncing inode

On Thu, Mar 31, 2022 at 5:59 PM Sasha Levin <sashal@...nel.org> wrote:
>
> On Tue, Mar 29, 2022 at 10:59:33AM +0100, Filipe Manana wrote:
> >On Mon, Mar 28, 2022 at 03:41:52PM -0400, Sasha Levin wrote:
> >> From: Filipe Manana <fdmanana@...e.com>
> >>
> >> [ Upstream commit 23e3337faf73e5bb2610697977e175313d48acb0 ]
> >>
> >> When an inode has a last_reflink_trans matching the current transaction,
> >> we have to take special care when logging its checksums in order to
> >> avoid getting checksum items with overlapping ranges in a log tree,
> >> which could result in missing checksums after log replay (more on that
> >> in the changelogs of commit 40e046acbd2f36 ("Btrfs: fix missing data
> >> checksums after replaying a log tree") and commit e289f03ea79bbc ("btrfs:
> >> fix corrupt log due to concurrent fsync of inodes with shared extents")).
> >> We also need to make sure a full fsync will copy all old file extent
> >> items it finds in modified leaves, because they might have been copied
> >> from some other inode.
> >>
> >> However once we fsync an inode, we don't need to keep paying the price of
> >> that extra special care in future fsyncs done in the same transaction,
> >> unless the inode is used for another reflink operation or the full sync
> >> flag is set on it (truncate, failure to allocate extent maps for holes,
> >> and other exceptional and infrequent cases).
> >>
> >> So after we fsync an inode reset its last_unlink_trans to zero. In case
> >> another reflink happens, we continue to update the last_reflink_trans of
> >> the inode, just as before. Also set last_reflink_trans to the generation
> >> of the last transaction that modified the inode whenever we need to set
> >> the full sync flag on the inode, just like when we need to load an inode
> >> from disk after eviction.
> >>
> >> Signed-off-by: Filipe Manana <fdmanana@...e.com>
> >> Signed-off-by: David Sterba <dsterba@...e.com>
> >> Signed-off-by: Sasha Levin <sashal@...nel.org>
> >
> >What's the motivation to backport this to stable?
> >
> >It doesn't fix a bug or any regression, as far as I know at least.
> >Or is it to make some other backport easier?
>
> I wasn't sure if it's needed for completeness for the mentioned fixes,
> so I took it. Can drop it if it's not needed.

Yes, please drop it. It's not needed (nor was intended) to go to any
stable releases.

Thanks.

>
> --
> Thanks,
> Sasha