On 3/26/15 12:25 PM, Filipe David Manana wrote: > On Thu, Mar 26, 2015 at 5:11 PM, Eric Sandeen <sand...@redhat.com> wrote: >> On 3/26/15 9:48 AM, Chris Mason wrote: >>> On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen <sand...@redhat.com> wrote: >> >> ... >> >>>>>> 9c4f61f btrfs: simplify insert_orphan_item >>>>>> >>>>>> made the whole path alloc/free go away. >>>> >>>> so I think there's no need for my patch; may as well just send the above >>>> to stable >>>> and fix it that way, as long as 9c4f61f is deemed safe & correct, I think. >>> >>> Nice catch, thanks Eric. 9c4f61f looks fine for stable to me, but >>> since he's already testing on stable, I talked Eric into giving it a >>> pass through xfstests before I send it up. >>> >>> -chris >> >> ./check -g auto on 3.19-stable-ish seems fine-ish. Certainly no worse w/ >> the patch added :) >> >> Failures: btrfs/010 btrfs/017 btrfs/078 generic/015 generic/039 generic/040 >> generic/041 generic/065 generic/066 generic/071 generic/204 >> Failed 11 of 202 tests > > Just curious, how did btrfs/078 fail? It isn't supposed to fail on > 3.19.x nor 3.18.x.
This was the use after free / segfault / valgrind splat from userspace that I reported yesterday. btrfs/078 104s ... 106s *** glibc detected *** btrfs check: double free or corruption (fasttop): 0x0000000000c12a40 *** ... ./common/rc: line 1932: 43334 Aborted btrfsck $device > $tmp.fsck 2>&1 _check_btrfs_filesystem: filesystem on /dev/sdc5 is inconsistent (see /mnt/test2/git/xfstests/results//btrfs/078.full) Ran: btrfs/078 Failures: btrfs/078 Failed 1 of 1 tests -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
