linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 0/8][v4] Cleanup how we handle root refs, part 2
Date: Fri, 14 Feb 2020 16:11:39 -0500	[thread overview]
Message-ID: <20200214211147.24610-1-josef@toxicpanda.com> (raw)

v3->v4:
- Rebased onto the latest misc-next, there were some subtle conflicts and
  weirdness with the automatic merge, so resending.

v2->v3:
- Rebased onto the latest misc-next, so the snapshot aware defrag related
  patches got dropped.

v1->v2:
- Fixed a error missed put in an error condition in relink_extent_backref
- Added "btrfs: make the init of static elements in fs_info" so that we could
  clean up fs_info init and make the leak detectors work for the self tests.

-- original email --
In testing with the recent fsstress I stumbled upon a deadlock in how we deal
with disappearing subvolumes.  We sort of half-ass a srcu lock to protect us,
but it's used inconsistently so doesn't really provide us with actual
protection, mostly it just makes us feel good.

In order to do away with this srcu thing we need to have proper ref counting for
our roots.  We currently refcount them, but only to handle the actual kfree, it
doesn't really control the lifetime of the root.  And again, this is not done in
any sort of consistent manner so it doesn't actually protect us.

This is the first set of patches, and yes I realize there are a lot of them.
Most of them are just "hold a ref on the root" in all of the call sites that
called btrfs_read_fs_root*() variations.  Now that we're going to actually hold
references to roots we need to make sure we put the reference when we're done
with them, so these patches go through each callsite and make sure we drop the
references appropriately.

Then there's a variety of cleanups and consolidations to make things clearer and
make it so we only have 1 place to get roots.

Finally there's the root leak detection patch.  I used this with a bunch of
testing to make sure I was never leaking roots with these patches.  I've been
testing these for several weeks cleaning up all the corners, so they should be
in relatively good shape.  Most of the patches are small so straightforward to
review.

This is just part 1, this is the prep work we need to make the root lifetime a
little saner, and will allow us to drop the subvol srcu, as well as the inode
rbtree.  It doesn't really fundamentally change how roots are handled other than
making the refcounting actually protect us from freeing the root while we're
using it.  That work will come later.  Thanks,

Josef



             reply	other threads:[~2020-02-14 21:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14 21:11 Josef Bacik [this message]
2020-02-14 21:11 ` [PATCH 1/8] btrfs: make the extent buffer leak check per fs info Josef Bacik
2020-02-19 13:59   ` Nikolay Borisov
2020-02-20 15:49     ` Josef Bacik
2020-02-14 21:11 ` [PATCH 2/8] btrfs: move ino_cache_inode dropping Josef Bacik
2020-02-14 21:11 ` [PATCH 3/8] btrfs: move the root freeing stuff into btrfs_put_root Josef Bacik
2020-02-19 15:10   ` Nikolay Borisov
2020-02-20 15:48     ` Josef Bacik
2020-02-14 21:11 ` [PATCH 4/8] btrfs: make inodes hold a ref on their roots Josef Bacik
2020-02-14 21:11 ` [PATCH 5/8] btrfs: hold a ref on the root on the dead roots list Josef Bacik
2020-02-14 21:11 ` [PATCH 6/8] btrfs: don't take an extra root ref at allocation time Josef Bacik
2020-02-14 21:11 ` [PATCH 7/8] btrfs: make btrfs_cleanup_fs_roots use the fs_roots_radix_lock Josef Bacik
2020-02-14 21:11 ` [PATCH 8/8] btrfs: kill the subvol_srcu Josef Bacik
2020-03-13 21:19 ` [PATCH 0/8][v4] Cleanup how we handle root refs, part 2 David Sterba

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=20200214211147.24610-1-josef@toxicpanda.com \
    --to=josef@toxicpanda.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 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).