All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: David Sterba <dsterba@suse.cz>
Cc: Filipe Manana <fdmanana@kernel.org>,
	linux-btrfs@vger.kernel.org, kernel-team@fb.com,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH v2] btrfs: fix tree mod log mishandling of reallocated nodes
Date: Mon, 17 Oct 2022 14:09:11 -0400	[thread overview]
Message-ID: <Y02aR4/PyHR/SCuA@localhost.localdomain> (raw)
In-Reply-To: <20221017135112.GP13389@twin.jikos.cz>

On Mon, Oct 17, 2022 at 03:51:12PM +0200, David Sterba wrote:
> On Mon, Oct 17, 2022 at 02:43:47PM +0100, Filipe Manana wrote:
> > > > Fixes: bd989ba359f2 ("Btrfs: add tree modification log functions")
> > > 
> > > Are you sure it's caused by this commit? 
> > > 
> > > The code was added in 485df7555425 ("btrfs: always pin deleted leaves
> > > when there are active tree mod log users") and slightly modified in
> > > 888dd183390d ("btrfs: use the new bit BTRFS_FS_TREE_MOD_LOG_USERS at
> > > btrfs_free_tree_block()").
> > 
> > The fixes tag is correct.
> > 
> > Not dealing correctly with extent buffers that get freed and reallocated
> > for multiple root nodes is something that exists since the tree mod log
> > was added.
> > 
> > The commits you mentioned were for a different problem, pinning only leaves,
> > while Josef's fix simply changes the logic to pin any extent buffer - it's
> > the simplest way to fix the bug regarding root replacements.
> > 
> > If those commits didn't exist, the fix this problem would be the same (just
> > pin any extent buffer if there are tree mod log users).
> 
> Ok, thanks. I'll tag it for stable 3.3 then but we'll need a backport
> for <= 5.10, ideally applicable down to 4.9.

Once you ship it to Linus let me know and I'll do the backports.  Thanks,

Josef

      reply	other threads:[~2022-10-17 18:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14 12:52 [PATCH v2] btrfs: fix tree mod log mishandling of reallocated nodes Josef Bacik
2022-10-17 13:31 ` David Sterba
2022-10-17 13:43   ` Filipe Manana
2022-10-17 13:51     ` David Sterba
2022-10-17 18:09       ` Josef Bacik [this message]

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=Y02aR4/PyHR/SCuA@localhost.localdomain \
    --to=josef@toxicpanda.com \
    --cc=dsterba@suse.cz \
    --cc=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.