On Wed, Jun 08, 2016 at 01:13:03PM +0800, Lu Fengqi wrote: > Only in the case of different root_id or different object_id, check_shared > identified extent as the shared. However, If a extent was referred by > different offset of same file, it should also be identified as shared. > In addition, check_shared's loop scale is at least n^3, so if a extent > has too many references, even causes soft hang up. > > First, add all delayed_ref to the ref_tree and calculate the unqiue_refs, > if the unique_refs is greater than one, return BACKREF_FOUND_SHARED. > Then individually add the on-disk reference(inline/keyed) to the ref_tree > and calculate the unique_refs of the ref_tree to check if the unique_refs > is greater than one.Because once there are two references to return > SHARED, so the time complexity is close to the constant. > > Reported-by: Tsutomu Itoh <t-i...@jp.fujitsu.com> > Signed-off-by: Lu Fengqi <lufq.f...@cn.fujitsu.com> > --- > The caller is fiemap that called from an ioctl. Because it isn't on a > writeout path, so we temporarily use GFP_KERNEL in ref_root_alloc() and > ref_tree_add(). If we use ref_tree replace the existing backref structure > later, we can consider whether to use GFP_NOFS again.
NACK. You don't need to be on a writeout path to deadlock, you simply need to be holding locks that the writeout path takes when you allocate. If the allocator does writeout to free memory then you deadlock. Fiemap is locking down extents which may also get locked down when you allocate within those locks. See my e-mail here for details, http://www.spinics.net/lists/linux-btrfs/msg55789.html --Mark -- Mark Fasheh -- 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
