mbox series

[0/9] btrfs: some free space cache fixes and updates

Message ID cover.1683196407.git.fdmanana@suse.com (mailing list archive)
Headers show
Series btrfs: some free space cache fixes and updates | expand

Message

Filipe Manana May 4, 2023, 11:04 a.m. UTC
From: Filipe Manana <fdmanana@suse.com>

Several updates to the free space cache code (most of it to the in memory
data structure, shared between the free space cache and the free space
tree). A bug fix, some cleanups, minor optimizations and adding several
asserts to verify we are holding the necessary lock(s) when udpating the
in memory space cache - this was motivated by an attempt to debug an
invalid memory access when manipulating the in memory free space cache,
as I suspected we had some code path not taking a required lock before
manipulating the in memory red black tree of free space entries.

Filipe Manana (9):
  btrfs: fix space cache inconsistency after error loading it from disk
  btrfs: avoid extra memory allocation when copying free space cache
  btrfs: avoid searching twice for previous node when merging free space entries
  btrfs: use precomputed end offsets at do_trimming()
  btrfs: simplify arguments to tree_insert_offset()
  btrfs: assert proper locks are held at tree_insert_offset()
  btrfs: assert tree lock is held when searching for free space entries
  btrfs: assert tree lock is held when linking free space
  btrfs: assert tree lock is held when removing free space entries

 fs/btrfs/free-space-cache.c | 111 +++++++++++++++++++++++-------------
 1 file changed, 72 insertions(+), 39 deletions(-)

Comments

David Sterba May 5, 2023, 8:51 p.m. UTC | #1
On Thu, May 04, 2023 at 12:04:17PM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> Several updates to the free space cache code (most of it to the in memory
> data structure, shared between the free space cache and the free space
> tree). A bug fix, some cleanups, minor optimizations and adding several
> asserts to verify we are holding the necessary lock(s) when udpating the
> in memory space cache - this was motivated by an attempt to debug an
> invalid memory access when manipulating the in memory free space cache,
> as I suspected we had some code path not taking a required lock before
> manipulating the in memory red black tree of free space entries.
> 
> Filipe Manana (9):
>   btrfs: fix space cache inconsistency after error loading it from disk

Oh, that was an old bug.

>   btrfs: avoid extra memory allocation when copying free space cache
>   btrfs: avoid searching twice for previous node when merging free space entries
>   btrfs: use precomputed end offsets at do_trimming()
>   btrfs: simplify arguments to tree_insert_offset()
>   btrfs: assert proper locks are held at tree_insert_offset()
>   btrfs: assert tree lock is held when searching for free space entries
>   btrfs: assert tree lock is held when linking free space
>   btrfs: assert tree lock is held when removing free space entries

Added to misc-next, thanks.