Re: kdave/for-next commit 26112f7f472

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

 



On Fri, Jul 08, 2016 at 07:55:47AM -0400, Jeff Mahoney wrote:
> >> The problem is that btrfs_calc_reclaim_metadata_size didn't used to be
> >> called from recovery, so it was safe to use fs_info->fs_root.  With
> >> commit 7c83c6a09 (Btrfs: don't bother kicking async if there's nothing
> >> to reclaim) we do call it from recovery context and fs_info->fs_root is
> >> NULL.
> >>
> >> The fix is to just not switch btrfs_calc_reclaim_metadata_size to take
> >> an fs_info.  All the other call sites were using fs_info->fs_root
> >> anyway, so it's not like we're pinning a root somewhere just for this call.
> > 
> > I've had this patch from last October in my 4.4.x tree forever:
> > http://www.spinics.net/lists/linux-btrfs/msg48457.html
> > 
> > Apparently it fell off the table. Shouldn't that fix it?
> 
> A different fix went into for-next.

Which JFI is https://patchwork.kernel.org/patch/8928981/ so the fix from
Tsutomu Itoh is not relevant anymore (but yeah it was lost in the
noise).
--
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