search for: bug_ons

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

Hi, all Those days, we spent some efforts to check severe error handling (panic, BUG_ON, BUG, ASSERT) in XEN. We have several round internal discussions as well as several mail threads with Keir. Below is the discussion writeup. If agreed, after review, we want to place it in XEN document folder or XEN wiki since we think it might be helpful to developers. Thanks a lot for your help! Regards,

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

There are many BUG_ON in zsmalloc.c which is not recommened so change them as alternatives. Normal rule is as follows: 1. avoid BUG_ON if possible. Instead, use VM_BUG_ON or VM_BUG_ON_PAGE 2. use VM_BUG_ON_PAGE if we need to see struct page's fields 3. use those assertion in primitive functions so higher functions can rely on the assertion in the primitive function. 4. Don't use

There were a whole bunch and I was doing it for other things. I haven''t tested these error paths but at the very least this is better than panicing. I''ve only left 2 BUG_ON()''s since they are logic errors and I want to replace them with a ASSERT framework that we can compile out for production users. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> ---

This patch changes some BUG_ON() to the error return. (but, most callers still use BUG_ON()) Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> --- fs/btrfs/ctree.c | 3 ++- fs/btrfs/disk-io.c | 5 ++++- fs/btrfs/extent-tree.c | 25 ++++++++++++++++++------- fs/btrfs/file-item.c | 3 ++- fs/btrfs/inode-map.c | 3 ++- fs/btrfs/ioctl.c | 5 ++++-

b->args[] has MC_ARGS elements, so the comparison here should be ">=" instead of ">". Otherwise we read past the end of the array one space. Signed-off-by: Dan Carpenter <error27 at gmail.com> --- This is a static checker patch and I haven't tested it. Please review carefully. diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c index

b->args[] has MC_ARGS elements, so the comparison here should be ">=" instead of ">". Otherwise we read past the end of the array one space. Signed-off-by: Dan Carpenter <error27 at gmail.com> --- This is a static checker patch and I haven't tested it. Please review carefully. diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c index

b->args[] has MC_ARGS elements, so the comparison here should be ">=" instead of ">". Otherwise we read past the end of the array one space. Signed-off-by: Dan Carpenter <error27 at gmail.com> --- This is a static checker patch and I haven't tested it. Please review carefully. diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c index

Dave Airlie <airlied at gmail.com> writes: > Hi Rusty, > > current virtio-ring.c has a BUG_ON in virtqueue_add that checks > total_sg > vg->vring.num, however I'm not sure it really is 100% > correct. > > If I have an indirect ring and I'm adding sgs to it and the host is > delayed (say I've got a thread consuming things from the vring and its >

Dave Airlie <airlied at gmail.com> writes: > Hi Rusty, > > current virtio-ring.c has a BUG_ON in virtqueue_add that checks > total_sg > vg->vring.num, however I'm not sure it really is 100% > correct. > > If I have an indirect ring and I'm adding sgs to it and the host is > delayed (say I've got a thread consuming things from the vring and its >

Please pull from 'upstream-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus to receive the following updates: fs/ocfs2/aops.c | 20 ++++++++++---------- fs/ocfs2/cluster/masklog.c | 3 +-- 2 files changed, 11 insertions(+), 12 deletions(-) Mark Fasheh: ocfs2: Fix invalid assertion during write on 64k pages Tiger

To make Btrfs code more robust, several return value checks where memory allocation can fail are introduced. I use BUG_ON where I don''t know how to handle the error properly, which increases the number of using the notorious BUG_ON, though. Signed-off-by: Yoshinori Sano <yoshinori.sano@gmail.com> --- fs/btrfs/compression.c | 6 ++++++ fs/btrfs/extent-tree.c | 2 ++

The memory allocation failure is BUG_ON in add_excluded_extent (following the code path). No need to BUG_ON -ENOMEM inside btrfs_alloc_logged_file_extent. Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> --- fs/btrfs/extent-tree.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 95492cc..9b9a6fa 100644 ---

Hi, I'm hitting this bug with both ext4 and btrfs. Here's an example of the backtrace: https://gist.github.com/vzctl/e888a821333979120932 I tried raising this BUG only for direct ring and it solved the problem: - BUG_ON(total_sg > vq->vring.num); + BUG_ON(total_sg > vq->vring.num && !vq->indirect); Shall I submit the patch or is a more elaborate fix

Hi, I'm hitting this bug with both ext4 and btrfs. Here's an example of the backtrace: https://gist.github.com/vzctl/e888a821333979120932 I tried raising this BUG only for direct ring and it solved the problem: - BUG_ON(total_sg > vq->vring.num); + BUG_ON(total_sg > vq->vring.num && !vq->indirect); Shall I submit the patch or is a more elaborate fix

When making btrfs filesystem. we firstly write root leaf to specified filed, and then we recow the root. If we don''t recow, some trees are not in the correct block group. Steps to reproduce: dd if=/dev/zero of=test.img bs=1M count=100 mkfs.btrfs -f test.img btrfs-debug-tree test.img extent tree key (EXTENT_TREE ROOT_ITEM 0) leaf 4210688 items 10 free space 3349 generation 4 owner 2

When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on the {rd,wr}msr instructions. This makes serious issues (either on the guest kernel, or on the host) be silently ignored, and is different from the native MSR code (which does not ignore the exceptions). As paravirt.h already includes linux/bug.h, I don't see what was the original issue preventing BUG_ON from being used.

When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on the {rd,wr}msr instructions. This makes serious issues (either on the guest kernel, or on the host) be silently ignored, and is different from the native MSR code (which does not ignore the exceptions). As paravirt.h already includes linux/bug.h, I don't see what was the original issue preventing BUG_ON from being used.

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