[PATCH v2 5/7] Btrfs: remove BUG() in add_data_reference

Now that we have a helper to report invalid value of extent inline ref type, we need to quit gracefully instead of throwing out a kernel panic. Signed-off-by: Liu Bo --- fs/btrfs/relocation.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v2 7/7] Btrfs: add one more sanity check for shared ref type

Every shared ref has a parent tree block, which can be get from btrfs_extent_inline_ref_offset(). And the tree block must be aligned to the nodesize, so we'd know this inline ref is not valid if this block's bytenr is not aligned to the nodesize, in which case, most likely the ref type has been

[PATCH v2 1/7] Btrfs: add a helper to retrive extent inline ref type

An invalid value of extent inline ref type may be read from a malicious image which may force btrfs to crash. This adds a helper which does sanity check for the ref type, so we can know if it's sane, return type if so, otherwise return an error. v2: add enum type and return

[PATCH v2 2/7] Btrfs: convert to use btrfs_get_extent_inline_ref_type

Since we have a helper which can do sanity check, this converts all btrfs_extent_inline_ref_type to it. Signed-off-by: Liu Bo --- fs/btrfs/backref.c | 11 +-- fs/btrfs/extent-tree.c | 36 ++-- fs/btrfs/relocation.c | 13

[PATCH v2 6/7] Btrfs: remove BUG_ON in __add_tree_block

The BUG_ON() can be triggered when the caller is processing an invalid extent inline ref, e.g. a shared data ref is offered instead of a extent data ref, such that it tries to find a non-exist tree block and then btrfs_search_slot returns 1 for no such item. This replaces the BUG_ON() with a

[PATCH v2 4/7] Btrfs: remove BUG() in print_extent_item

btrfs_print_leaf() is used in btrfs_get_extent_inline_ref_type, so here we really want to print the invalid value of ref type instead of causing a kernel panic. Signed-off-by: Liu Bo --- fs/btrfs/print-tree.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

[PATCH v2 3/7] Btrfs: remove BUG() in btrfs_extent_inline_ref_size

Now that btrfs_get_extent_inline_ref_type() can report if type is a valid one and all callers can gracefully deal with that, we don't need to crash here. Signed-off-by: Liu Bo --- fs/btrfs/ctree.h | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/btrfs/ctree.h

[PATCH v2 0/7] add sanity check for extent inline ref type

An invalid extent inline ref type could be read from a btrfs image and it ends up with a panic[1], this set is to deal with the insane value gracefully in patch 1-2 and clean up BUG() in the code in patch 3-6. Patch 7 adds one more check to see if the ref is a valid shared one. I'm not sure in

Re: kernel BUG at /build/linux-H5UzH8/linux-4.10.0/fs/btrfs/extent_io.c:2318

Piotr Pawłow posted on Mon, 07 Aug 2017 15:26:16 +0200 as excerpted: > # uname -a > Linux pps 4.10.0-30-generic #34-Ubuntu SMP > Mon Jul 31 19:38:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux This is a general principles reply and chances are wouldn't help with your issue since the spread isn't

[PATCH] Btrfs: fix out of bounds array access while reading extent buffer

There is a cornel case that slip through the checkers in functions reading extent buffer, ie. if (start < eb->len) and (start + len > eb->len), then a) map_private_extent_buffer() returns immediately because it's thinking the range spans across two pages, b) and the checkers in

Re: Btrfs umount hang

On 8/7/17 1:19 PM, Jeff Mahoney wrote: > On 8/7/17 10:12 AM, Angel Shtilianov wrote: >> Hi there, >> I'm investigating sporadic hanging during btrfs umount. The FS is >> contained in a loop mounted file. >> I have no reproduction scenario and the issue may happen once a day or >> once a month. It

Re: Btrfs umount hang

On 8/7/17 10:12 AM, Angel Shtilianov wrote: > Hi there, > I'm investigating sporadic hanging during btrfs umount. The FS is > contained in a loop mounted file. > I have no reproduction scenario and the issue may happen once a day or > once a month. It is rare, but frustrating. > I have a crashdump

Re: Btrfs umount hang

On 7.08.2017 17:12, Angel Shtilianov wrote: > Hi there, > I'm investigating sporadic hanging during btrfs umount. The FS is > contained in a loop mounted file. > I have no reproduction scenario and the issue may happen once a day or > once a month. It is rare, but frustrating. > I have a

Re: RedHat 7.4 Release Notes: "Btrfs has been deprecated" - wut?

On Fri, Aug 4, 2017 at 8:05 AM, Qu Wenruo wrote: > > For example, if one day there is some dm-csum to support verify csum of > given ranges (and skip unrelated ones specified by higher levels), btrfs > support for data csum is no longer an exclusive feature. How would

Btrfs umount hang

Hi there, I'm investigating sporadic hanging during btrfs umount. The FS is contained in a loop mounted file. I have no reproduction scenario and the issue may happen once a day or once a month. It is rare, but frustrating. I have a crashdump (the server has been manually crashed and collected a

kernel BUG at /build/linux-H5UzH8/linux-4.10.0/fs/btrfs/extent_io.c:2318

Hello, my btrfs raid1 fs with 4 drives crashed after only one drive developed a couple of bad blocks. Seems similar to https://bugzilla.kernel.org/show_bug.cgi?id=196251 but it happened during normal usage instead of during replace. As a sidenote, I tried to make the system less noisy during

Re: Crashed filesystem, nothing helps

On Mon, Aug 7, 2017 at 7:12 AM, Thomas Wurfbaum wrote: > Now i do a btrfs-find-root, but it runs now since 5 day without a result. > How long should i wait? Or is it already to late to hope? > > mainframe:~ # btrfs-find-root.static /dev/sdb1 > parent transid verify failed on

Re: Power down tests...

Hi Chris, Good points that you make. We're making use of btrfs raid only. (One of the reasons we want to move to btrfs) However, during this test, we haven't run with multi-disk btrfs raid. We just have one disk. (This test setup doesn't have too many disks) We do have our metadata replicated as

Re: Power down tests...

Hi Chris, Thanks for the detailed reply. :) Read my answers inline: On Mon, Aug 7, 2017 at 7:45 AM, Chris Murphy wrote: > > This is astronomically more complicated than the already complicated > scenario with one file system on a single normal partition of a well >