March 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1025080] New: Btrfs: send, fix corner case for reference overwrite detection
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025080 Bug ID: 1025080 Summary: Btrfs: send, fix corner case for reference overwrite detection Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Filipe Manana <fdmanana(a)suse.com> Date: Sat, 26 Sep 2015 15:30:23 +0100 Subject: Btrfs: send, fix corner case for reference overwrite detection Git-commit: b786f16ac3c5d4f7a5fd136656b6a1301b29b73b Patch-mainline: v4.3-rc6 References: Fixes tag When the inode given to did_overwrite_ref() matches the current progress and has a reference that collides with the reference of other inode that has the same number as the current progress, we were always telling our caller that the inode's reference was overwritten, which is incorrect because the other inode might be a new inode (different generation number) in which case we must return false from did_overwrite_ref() so that its callers don't use an orphanized path for the inode (as it will never be orphanized, instead it will be unlinked and the new inode created later). The following test case for fstests reproduces the issue: seq=`basename $0` seqres=$RESULT_DIR/$seq echo "QA output created by $seq" tmp=/tmp/$$ status=1 # failure is the default! trap "_cleanup; exit \$status" 0 1 2 3 15 _cleanup() { rm -fr $send_files_dir rm -f $tmp.* } # get standard environment, filters and checks . ./common/rc . ./common/filter # real QA test starts here _supported_fs btrfs _supported_os Linux _require_scratch _need_to_be_root send_files_dir=$TEST_DIR/btrfs-test-$seq rm -f $seqres.full rm -fr $send_files_dir mkdir $send_files_dir _scratch_mkfs >>$seqres.full 2>&1 _scratch_mount # Create our test file with a single extent of 64K. mkdir -p $SCRATCH_MNT/foo $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 64K" $SCRATCH_MNT/foo/bar \ | _filter_xfs_io _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT \ $SCRATCH_MNT/mysnap1 _run_btrfs_util_prog subvolume snapshot $SCRATCH_MNT \ $SCRATCH_MNT/mysnap2 echo "File digest before being replaced:" md5sum $SCRATCH_MNT/mysnap1/foo/bar | _filter_scratch # Remove the file and then create a new one in the same location with # the same name but with different content. This new file ends up # getting the same inode number as the previous one, because that inode # number was the highest inode number used by the snapshot's root and # therefore when attempting to find the a new inode number for the new # file, we end up reusing the same inode number. This happens because # currently btrfs uses the highest inode number summed by 1 for the # first inode created once a snapshot's root is loaded (done at # fs/btrfs/inode-map.c:btrfs_find_free_objectid in the linux kernel # tree). # Having these two different files in the snapshots with the same inode # number (but different generation numbers) caused the btrfs send code # to emit an incorrect path for the file when issuing an unlink # operation because it failed to realize they were different files. rm -f $SCRATCH_MNT/mysnap2/foo/bar $XFS_IO_PROG -f -c "pwrite -S 0xbb 0 96K" \ $SCRATCH_MNT/mysnap2/foo/bar | _filter_xfs_io _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT/mysnap2 \ $SCRATCH_MNT/mysnap2_ro _run_btrfs_util_prog send $SCRATCH_MNT/mysnap1 -f $send_files_dir/1.snap _run_btrfs_util_prog send -p $SCRATCH_MNT/mysnap1 \ $SCRATCH_MNT/mysnap2_ro -f $send_files_dir/2.snap echo "File digest in the original filesystem after being replaced:" md5sum $SCRATCH_MNT/mysnap2_ro/foo/bar | _filter_scratch # Now recreate the filesystem by receiving both send streams and verify # we get the same file contents that the original filesystem had. _scratch_unmount _scratch_mkfs >>$seqres.full 2>&1 _scratch_mount _run_btrfs_util_prog receive -vv $SCRATCH_MNT -f $send_files_dir/1.snap _run_btrfs_util_prog receive -vv $SCRATCH_MNT -f $send_files_dir/2.snap echo "File digest in the new filesystem:" # Must match the digest from the new file. md5sum $SCRATCH_MNT/mysnap2_ro/foo/bar | _filter_scratch status=0 exit Reported-by: Martin Raiber <martin(a)urbackup.org> Fixes: 8b191a684968 ("Btrfs: incremental send, check if orphanized dir inode needs delayed rename") Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/send.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025079] New: btrfs: delayed-ref: double free in btrfs_add_delayed_tree_ref()
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025079 Bug ID: 1025079 Summary: btrfs: delayed-ref: double free in btrfs_add_delayed_tree_ref() Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 24 Jun 2015 17:32:33 +0300 Subject: btrfs: delayed-ref: double free in btrfs_add_delayed_tree_ref() Git-commit: 5a5003df98d5a7f6834227885b7c9728f767cc27 Patch-mainline: v4.2-rc2 References: Fixes tag There is a cut and paste error so instead of freeing "head_ref", we free "ref" twice. Fixes: 3368d001ba5d ('btrfs: qgroup: Record possible quota-related extent for qgroup.') Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Chris Mason <clm(a)fb.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/delayed-ref.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1025077] New: Btrfs: fix qgroup rescan worker initialization
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025077 Bug ID: 1025077 Summary: Btrfs: fix qgroup rescan worker initialization Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Filipe Manana <fdmanana(a)suse.com> Date: Thu, 24 Nov 2016 02:09:04 +0000 Subject: Btrfs: fix qgroup rescan worker initialization Git-commit: 8d9eddad19467b008e0c881bc3133d7da94b7ec1 Patch-mainline: v4.10-rc1 References: pulled from 4.4-stable (4.1-stable had expired) We were setting the qgroup_rescan_running flag to true only after the rescan worker started (which is a task run by a queue). So if a user space task starts a rescan and immediately after asks to wait for the rescan worker to finish, this second call might happen before the rescan worker task starts running, in which case the rescan wait ioctl returns immediatley, not waiting for the rescan worker to finish. This was making the fstest btrfs/022 fail very often. Fixes: d2c609b834d6 (btrfs: properly track when rescan worker is running) Cc: stable(a)vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/qgroup.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1025076] New: Btrfs: don't BUG() during drop snapshot
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025076 Bug ID: 1025076 Summary: Btrfs: don't BUG() during drop snapshot Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Josef Bacik <jbacik(a)fb.com> Date: Fri, 23 Sep 2016 13:23:28 +0200 Subject: Btrfs: don't BUG() during drop snapshot Git-commit: 4867268c57ff709a7b6b86ae6f6537d846d1443a Patch-mainline: v4.9-rc1 References: pulled from 4.4-stable (4.1-stable had expired) Really there's lots of things that can go wrong here, kill all the BUG_ON()'s and replace the logic ones with ASSERT()'s and return EIO instead. Signed-off-by: Josef Bacik <jbacik(a)fb.com> [ switched to btrfs_err, errors go to common label ] Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/extent-tree.c | 38 +++++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025075] New: Btrfs: fix memory leak in do_walk_down
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025075 Bug ID: 1025075 Summary: Btrfs: fix memory leak in do_walk_down Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Liu Bo <bo.li.liu(a)oracle.com> Date: Tue, 13 Sep 2016 19:02:27 -0700 Subject: Btrfs: fix memory leak in do_walk_down Git-commit: a958eab0ed7fdc1b977bc25d3af6efedaa945488 Patch-mainline: v4.9-rc1 References: pulled from 4.4-stable (4.1-stable had expired) The extent buffer 'next' needs to be free'd conditionally. Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/extent-tree.c | 1 + 1 file changed, 1 insertion(+) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1025074] New: Btrfs: don't leak reloc root nodes on error
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025074 Bug ID: 1025074 Summary: Btrfs: don't leak reloc root nodes on error Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Josef Bacik <jbacik(a)fb.com> Date: Fri, 2 Sep 2016 15:25:43 -0400 Subject: Btrfs: don't leak reloc root nodes on error Git-commit: 6bdf131fac2336adb1a628f992ba32384f653a55 Patch-mainline: v4.9-rc1 References: pulled from 4.4-stable (4.1-stable had expired) We don't track the reloc roots in any sort of normal way, so the only way the root/commit_root nodes get free'd is if the relocation finishes successfully and the reloc root is deleted. Fix this by free'ing them in free_reloc_roots. Thanks, Signed-off-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/relocation.c | 4 ++++ 1 file changed, 4 insertions(+) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025073] New: Btrfs: return gracefully from balance if fs tree is corrupted
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025073 Bug ID: 1025073 Summary: Btrfs: return gracefully from balance if fs tree is corrupted Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Liu Bo <bo.li.liu(a)oracle.com> Date: Wed, 14 Sep 2016 08:51:46 -0700 Subject: Btrfs: return gracefully from balance if fs tree is corrupted Git-commit: 3561b9db70928f207be4570b48fc19898eeaef54 Patch-mainline: v4.9-rc1 References: pulled from 4.4-stable (4.1-stable had expired) When relocating tree blocks, we firstly get block information from back references in the extent tree, we then search fs tree to try to find all parents of a block. However, if fs tree is corrupted, eg. if there're some missing items, we could come across these WARN_ONs and BUG_ONs. This makes us print some error messages and return gracefully from balance. Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: Josef Bacik <jbacik(a)fb.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/relocation.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025072] New: Btrfs: bail out if block group has different mixed flag
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025072 Bug ID: 1025072 Summary: Btrfs: bail out if block group has different mixed flag Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Liu Bo <bo.li.liu(a)oracle.com> Date: Thu, 25 Aug 2016 18:08:27 -0700 Subject: Btrfs: bail out if block group has different mixed flag Git-commit: 49303381f19ab16a371a061b67e783d3f570d56e Patch-mainline: v4.9-rc1 References: pulled from 4.4-stable (4.1-stable had expired) Currently we allow inconsistence about mixed flag (BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA). We'd get ENOSPC if block group has mixed flag and btrfs doesn't. If that happens, we have one space_info with mixed flag and another space_info only with BTRFS_BLOCK_GROUP_METADATA, and global_block_rsv.space_info points to the latter one, but all bytes from block_group contributes to the mixed space_info, thus all the allocation will fail with ENOSPC. This adds a check for the above case. Reported-by: Vegard Nossum <vegard.nossum(a)oracle.com> Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> [ updated message ] Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/extent-tree.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1025071] New: Btrfs: fix memory leak in reading btree blocks
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025071 Bug ID: 1025071 Summary: Btrfs: fix memory leak in reading btree blocks Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Liu Bo <bo.li.liu(a)oracle.com> Date: Wed, 3 Aug 2016 12:33:01 -0700 Subject: Btrfs: fix memory leak in reading btree blocks Git-commit: 2571e739677f1e4c0c63f5ed49adcc0857923625 Patch-mainline: v4.9-rc1 References: pulled from 4.4-stable (4.1-stable had expired) So we can read a btree block via readahead or intentional read, and we can end up with a memory leak when something happens as follows, 1) readahead starts to read block A but does not wait for read completion, 2) btree_readpage_end_io_hook finds that block A is corrupted, and it needs to clear all block A's pages' uptodate bit. 3) meanwhile an intentional read kicks in and checks block A's pages' uptodate to decide which page needs to be read. 4) when some pages have the uptodate bit during 3)'s check so 3) doesn't count them for eb->io_pages, but they are later cleared by 2) so we has to readpage on the page, we get the wrong eb->io_pages which results in a memory leak of this block. This fixes the problem by firstly getting all pages's locking and then checking pages' uptodate bit. t1(readahead) t2(readahead endio) t3(the following read) read_extent_buffer_pages end_bio_extent_readpage for pg in eb: for page 0,1,2 in eb: if pg is uptodate: btree_readpage_end_io_hook(pg) num_reads++ if uptodate: eb->io_pages = num_reads SetPageUptodate(pg) _______________ for pg in eb: for page 3 in eb: read_extent_buffer_pages if pg is NOT uptodate: btree_readpage_end_io_hook(pg) for pg in eb: __extent_read_full_page(pg) sanity check reports something wrong if pg is uptodate: clear_extent_buffer_uptodate(eb) num_reads++ for pg in eb: eb->io_pages = num_reads ClearPageUptodate(page) _______________ for pg in eb: if pg is NOT uptodate: __extent_read_full_page(pg) So t3's eb->io_pages is not consistent with the number of pages it's reading, and during endio(), atomic_dec_and_test(&eb->io_pages) will get a negative number so that we're not able to free the eb. Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/extent_io.c | 9 +++++++++ 1 file changed, 9 insertions(+) -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1025070] New: btrfs: Continue write in case of can_not_nocow
by bugzilla_noreply＠novell.com 01 Mar '17

01 Mar '17

http://bugzilla.suse.com/show_bug.cgi?id=1025070 Bug ID: 1025070 Summary: btrfs: Continue write in case of can_not_nocow Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeffm(a)suse.com Reporter: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- From: Zhao Lei <zhaolei(a)cn.fujitsu.com> Date: Wed, 6 Jan 2016 18:24:43 +0800 Subject: btrfs: Continue write in case of can_not_nocow Git-commit: 4da2e26a2a32b174878744bd0f07db180c875f26 Patch-mainline: v4.6-rc2 References: pulled from 4.4-stable (4.1-stable had expired) btrfs failed in xfstests btrfs/080 with -o nodatacow. Can be reproduced by following script: DEV=/dev/vdg MNT=/mnt/tmp umount $DEV &>/dev/null mkfs.btrfs -f $DEV mount -o nodatacow $DEV $MNT dd if=/dev/zero of=$MNT/test bs=1 count=2048 & btrfs subvolume snapshot -r $MNT $MNT/test_snap & wait -- We can see dd failed on NO_SPACE. Reason: __btrfs_buffered_write should run cow write when no_cow impossible, and current code is designed with above logic. But check_can_nocow() have 2 type of return value(0 and <0) on can_not_no_cow, and current code only continue write on first case, the second case happened in doing subvolume. Fix: Continue write when check_can_nocow() return 0 and <0. Reviewed-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: Zhao Lei <zhaolei(a)cn.fujitsu.com> Acked-by: Jeff Mahoney <jeffm(a)suse.com> --- fs/btrfs/file.c | 37 +++++++++++++++++-------------------- 1 file changed, 17 insertions(+), 20 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.

1 5