Re: I think "btrfs: fix leak of path in btrfs_find_item" broke stable trees ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 26, 2015 at 12:11:51PM -0500, Eric Sandeen wrote:
> On 3/26/15 9:48 AM, Chris Mason wrote:
> > On Thu, Mar 26, 2015 at 10:11 AM, Eric Sandeen <sandeen@xxxxxxxxxx> 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 FYI.

I think generic/204 is a test case issue, _filter_mkfs failed to print
isize and dbsize for btrfs and test failed because of divide by zero
error.

--- /dev/fd/63	2015-03-25 12:17:05.987107715 -0400
+++ results/generic/204.out.bad		      2015-03-25 12:17:05.423101244 -0400
@@ -1,2 +1,3 @@
 QA output created by 204
 +./tests/generic/204: line 76: space / (isize + dbsize): division by 0 (error token is ")")
  *** done

I'm working a patch for fstests.

Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux