linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: dsterba@suse.cz, Filipe Manana <fdmanana@kernel.org>,
	Wang Yugui <wangyugui@e16-tech.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 5.10.x] btrfs: fix crash after non-aligned direct IO write with O_DSYNC
Date: Tue, 16 Feb 2021 14:41:43 +0000	[thread overview]
Message-ID: <CAL3q7H562aEiLRGTZKQdSRpaf8oAnLCN6yfitTomaOfMVKmKLw@mail.gmail.com> (raw)
In-Reply-To: <20210216142324.GO1993@twin.jikos.cz>

On Tue, Feb 16, 2021 at 2:25 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Mon, Feb 15, 2021 at 11:05:33AM +0000, Filipe Manana wrote:
> > On Sat, Feb 13, 2021 at 1:07 AM Wang Yugui <wangyugui@e16-tech.com> wrote:
> > > > This bug only affects 5.10 kernels, and the regression was introduced in
> > > > 5.10-rc1 by commit 0eb79294dbe328 ("btrfs: dio iomap DSYNC workaround").
> > > > The bug does not exist in 5.11 kernels due to commit ecfdc08b8cc65d
> > > > ("btrfs: remove dio iomap DSYNC workaround"), which depends on other
> > > > changes that went into the merge window for 5.11. So this is a fix only
> > > > for 5.10.x stable kernels, as there are people hitting this.
> > >
> > > It is OK too to backport commit ecfdc08b8cc65d
> > >  ("btrfs: remove dio iomap DSYNC workaround") to 5.10 for this problem?
> > >
> > > the iomap issue for commit 0eb79294dbe328 ("btrfs: dio iomap DSYNC workaround")
> > > is already fixed in 5.10?
> >
> > Quoting the changelog:
> >
> > "commit ecfdc08b8cc65d
> > ("btrfs: remove dio iomap DSYNC workaround"), which depends on other
> > changes that went into the merge window for 5.11."
> >
> > All the changes, are (at least):
> >
> > commit ecfdc08b8cc65d737eebc26a1ee1875a097fd6a0   --> 5.11-rc1
> > Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Date:   Thu Sep 24 11:39:21 2020 -0500
> >
> >     btrfs: remove dio iomap DSYNC workaround
> >
> > commit a42fa643169d2325602572633fcaa16862990e28
> > Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Date:   Thu Sep 24 11:39:20 2020 -0500
> >
> >     btrfs: call iomap_dio_complete() without inode_lock
> >
> > commit 502756b380938022c848761837f8fa3976906aa1
> > Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Date:   Thu Sep 24 11:39:19 2020 -0500
> >
> >     btrfs: remove btrfs_inode::dio_sem
> >
> > commit e9adabb9712ef9424cbbeeaa027d962ab5262e19
> > Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Date:   Thu Sep 24 11:39:18 2020 -0500
> >
> >     btrfs: use shared lock for direct writes within EOF
> >
> > commit c352370633400d13765cc88080c969799ea51108
> > Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Date:   Thu Sep 24 11:39:17 2020 -0500
> >
> >     btrfs: push inode locking and unlocking into buffered/direct write
> >
> > commit a14b78ad06aba0fa7e76d2bc13c5ba581a7f331a
> > Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Date:   Thu Sep 24 11:39:16 2020 -0500
> >
> >     btrfs: introduce btrfs_inode_lock()/unlock()
> >
> > commit b8d8e1fd570a194904f545b135efc880d96a41a4
> > Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > Date:   Thu Sep 24 11:39:15 2020 -0500
> >
> >     btrfs: introduce btrfs_write_check()
> >
> > That's probably too much to add to stable at once, plus I'm assuming
> > all required iomap dependencies are in 5.10 already (it seems so,
> > unless I missed something).
> >
> > Usually we don't add patches to stable that didn't go through Linus'
> > tree either (there were 1 or 2 very rare exceptions in the past I
> > think), but when a backport depends on so many patches, and not all
> > from the same patchset, the risk of getting something wrong is
> > significant. That's why I opted to send this patch, which is much more
> > simple.
>
> Agreed, in this case the backport would be too big, just the diffstat
> between b8d8e1fd570^..ecfdc08b8cc6 is
>
>  5 files changed, 213 insertions(+), 240 deletions(-)
>
> This fix is minimal and suitable for stable as an exception. You did not
> CC stable@vger.kernel.org so you'll need to send it again. Please CC me
> too in case there are some questions from stable team. Thanks.

Ah yes, my usual script to send patches suppresses all cc by default,
I missed that.
Ok, sent again. Thanks.

  reply	other threads:[~2021-02-16 14:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 17:00 [PATCH 5.10.x] btrfs: fix crash after non-aligned direct IO write with O_DSYNC fdmanana
2021-02-13  1:04 ` Wang Yugui
2021-02-15 11:05   ` Filipe Manana
2021-02-16 14:23     ` David Sterba
2021-02-16 14:41       ` Filipe Manana [this message]
2021-02-16 14:40 ` fdmanana
2021-02-16 14:50 ` Greg KH
2021-02-16 14:52   ` Filipe Manana
2021-02-16 15:15   ` David Sterba
2021-02-16 15:34     ` Greg KH
2021-02-16 17:52       ` David Sterba
2021-02-22 11:07         ` Greg KH

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=CAL3q7H562aEiLRGTZKQdSRpaf8oAnLCN6yfitTomaOfMVKmKLw@mail.gmail.com \
    --to=fdmanana@kernel.org \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wangyugui@e16-tech.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;
as well as URLs for NNTP newsgroup(s).