similar to: [PATCH 2/3] btrfs: remove unnecessary -ENOMEM BUG_ON check in extent-tree.c/btrfs_alloc_logged_file_extent

Hi guys, my computer suddenly failed to boot. It seams that it is unable to mount /home which is btrfs. Here are the messages I get during the boot (the relevant part; hopefully): Feb 02 13:59:58 Edge kernel: kernel BUG at fs/btrfs/extent-tree.c:6185! Feb 02 13:59:58 Edge kernel: invalid opcode: 0000 [#1] PREEMPT SMP Feb 02 13:59:58 Edge kernel: Modules linked in: joydev coretemp kvm_intel kvm

Document those places in the btrfs code which are BUGing on non-fatal error conditions that should be handled by proper error paths. This makes it easier to distinguish between what needs fixing versus which BUG_ON''s we might want to keep (to trap code bugs, unexpected inconsistencies, etc). Do this with a trivial macro, ''btrfs_fixable_bug_on'' which just defines to

Hello, My computer locked up and I had to press the reset button. Ever since then I can''t mount the btrfs filesystem, here''s the output: [ 37.645583] ------------[ cut here ]------------ [ 37.645598] WARNING: at fs/btrfs/free-space-cache.c:1887 btrfs_remove_free_space+0x329/0x350 [btrfs]() [ 37.645600] Modules linked in: btrfs zlib_deflate libcrc32c ext4 jbd2 mbcache crc16

worker_loop() uses schedule_timeout() without setting state to STATE_(UN)INTERRUPTIBLE. As it is called in cycle without checking of pending signals, use schedule_timeout_uninterruptible(). Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> --- fs/btrfs/async-thread.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c

The type of some functions that return only 0 is changed to ''void''. In addition, the check on the return value in the caller of these functions becomes unnecessary. So, these check is removed. Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/async-thread.c | 17 ++++-------- fs/btrfs/async-thread.h | 4 +- fs/btrfs/compression.c | 14 ++++------

Hi all, It seems like memory barrier is not required in cached_block_group.I am looking at kernel 2.6.34-rc2. cache_block_group(struct btrfs_block_group_cache *cache) { smp_mb(); if (cache->cached != BTRFS_CACHE_NO) return 0; .... } This function is called from btrfs_alloc_logged_file_extent and find_free_extent. In btrfs_alloc_logged_file_extent the code snippet is as follows

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

We have been using bytes_reserved for metadata reservations, which is wrong since we use that to keep track of outstanding reservations from the allocator. This resulted in us doing a lot of silly things to make sure we don''t allocate a bunch of metadata chunks since we never had a real view of how much space was actually in use by metadata. There are a lot of fixes in here to make this

If we have particularly full nodes, we could call btrfs_node_blockptr up to 32 times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the extent buffer while we look for readahead targets. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git

caching_thread()s do all their work under read access to extent_commit_sem. They give up on this read access only when need_resched() tells them, or when they exit. As a result, somebody that wants a WRITE access to this sem, might wait for a long time. Especially this is problematic in cache_block_group(), which can be called on critical paths like find_free_extent() and in commit path via

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

We keep hitting bugs in the tree log replay because btrfs_remove_free_space doesn''t account for some corner case. So add a bunch of tests to try and fully test btrfs_remove_free_space since the only time it is called is during tree log replay. These tests all finish successfully, so as we find more of these bugs we need to add to these tests to make sure we don''t regress in

On Wed, 2017-09-13 at 13:02 +0530, Allen Pais wrote: > Signed-off-by: Allen Pais <allen.lkml at gmail.com> I think the changelog for this series of conversions should show that you've validated the change by inspecting the return call chain at each modified line. Also, it seems you've cc'd the same mailing lists for all of the patches modified by this series. It would be

Signed-off-by: Allen Pais <allen.lkml at gmail.com> --- drivers/message/fusion/mptbase.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c index 84eab28..7920b2b 100644 --- a/drivers/message/fusion/mptbase.c +++ b/drivers/message/fusion/mptbase.c @@ -4328,15 +4328,15 @@

Signed-off-by: Allen Pais <allen.lkml at gmail.com> --- fs/btrfs/check-integrity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c index 7d5a9b5..efa4c23 100644 --- a/fs/btrfs/check-integrity.c +++ b/fs/btrfs/check-integrity.c @@ -2913,7 +2913,7 @@ int btrfsic_mount(struct btrfs_fs_info *fs_info, state =

Signed-off-by: Allen Pais <allen.lkml at gmail.com> --- drivers/net/bonding/bond_alb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c index c02cc81..89df377 100644 --- a/drivers/net/bonding/bond_alb.c +++ b/drivers/net/bonding/bond_alb.c @@ -864,7 +864,7 @@ static int rlb_initialize(struct bonding *bond)

> propagates the -1. That is only called by bond_open() with: > > if (bond_alb_initialize(bond, (BOND_MODE(bond) == BOND_MODE_ALB))) > return -ENOMEM; > > So you might want to also modify this code, to return the return > value, rather than use the hard coded ENOMEM. > I'll modify the above and send it out a separate patch. Thank you.

From: Allen Pais <allen.lkml at gmail.com> Date: Wed, 13 Sep 2017 13:02:15 +0530 > Signed-off-by: Allen Pais <allen.lkml at gmail.com> This is quite pointless as the caller doesn't do anything with the value, it just tests whether a negative value is returned or not.

> > static int cas_alloc_rxds(struct cas *cp) > { > int i; > > for (i = 0; i < N_RX_DESC_RINGS; i++) { > if (cas_alloc_rx_desc(cp, i) < 0) { > cas_free_rxds(cp); > return -1; > } > } > return 0; > } > > Again, your change is correct, but