[PATCH 6.6] btrfs: free path if inline extents in range_is_hole_in_parent()

[PATCH 6.6] btrfs: free path if inline extents in range_is_hole_in_parent()

[Hongbo Li]

Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
range_is_hole_in_parent()") is a patch backported directly from
mainline to 6.6, it does not free the path in the inline extents case.

Commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
conversions") in 6.18-rc1 fixes this by accident by converting to
BTRFS_PATH_AUTO_FREE, but we cannot backport this to 6.6 due to many
dependencies. Instead, we choose to use a goto statement to avoid the
memory leak in inline extents case.

Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in range_is_hole_in_parent()")
Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
---
 fs/btrfs/send.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 6768e2231d61..b107a33dfd4d 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -6545,8 +6545,10 @@ static int range_is_hole_in_parent(struct send_ctx *sctx,
 		extent_end = btrfs_file_extent_end(path);
 		if (extent_end <= start)
 			goto next;
-		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE)
-			return 0;
+		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
+			ret = 0;
+			goto out;
+		}
 		if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
 			search_start = extent_end;
 			goto next;
-- 
2.34.1

Re: [PATCH 6.6] btrfs: free path if inline extents in range_is_hole_in_parent()

[Qu Wenruo]

在 2026/2/27 17:14, Hongbo Li 写道:
> Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
> range_is_hole_in_parent()") is a patch backported directly from
> mainline to 6.6, it does not free the path in the inline extents case.
> 
> Commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
> conversions") in 6.18-rc1 fixes this by accident

It's not "by accident", it's the designed behavior, remember the fix is 
after that commit introducing scope-based auto-cleanup.

It's missing the dependency, which can not be directly backported, and 
considering the scope-based auto-cleanup makes is much harder to detect 
just by the patch context, it's indeed a problem.

> by converting to
> BTRFS_PATH_AUTO_FREE, but we cannot backport this to 6.6 due to many
> dependencies. Instead, we choose to use a goto statement to avoid the
> memory leak in inline extents case.
> 
> Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in range_is_hole_in_parent()")

With the commit message fixed it looks good to me.

> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
> ---
>   fs/btrfs/send.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
> index 6768e2231d61..b107a33dfd4d 100644
> --- a/fs/btrfs/send.c
> +++ b/fs/btrfs/send.c
> @@ -6545,8 +6545,10 @@ static int range_is_hole_in_parent(struct send_ctx *sctx,
>   		extent_end = btrfs_file_extent_end(path);
>   		if (extent_end <= start)
>   			goto next;
> -		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE)
> -			return 0;
> +		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
> +			ret = 0;
> +			goto out;
> +		}
>   		if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
>   			search_start = extent_end;
>   			goto next;

Re: [PATCH 6.6] btrfs: free path if inline extents in range_is_hole_in_parent()

[Qu Wenruo]

在 2026/2/27 17:18, Qu Wenruo 写道:
> 
> 
> 在 2026/2/27 17:14, Hongbo Li 写道:
>> Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
>> range_is_hole_in_parent()") is a patch backported directly from
>> mainline to 6.6, it does not free the path in the inline extents case.
>>
>> Commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
>> conversions") in 6.18-rc1 fixes this by accident
> 
> It's not "by accident", it's the designed behavior, remember the fix is 
> after that commit introducing scope-based auto-cleanup.

To be clear, all I mention here is based on upstream, not the stable 
commits.

Commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE 
conversions") is in v6.18, meanwhile commit 08b096c1372c ("btrfs: send: 
check for inline extents in range_is_hole_in_parent()") is in v6.19-rc6.

> 
> It's missing the dependency, which can not be directly backported, and 
> considering the scope-based auto-cleanup makes is much harder to detect 
> just by the patch context, it's indeed a problem.
> 
>> by converting to
>> BTRFS_PATH_AUTO_FREE, but we cannot backport this to 6.6 due to many
>> dependencies. Instead, we choose to use a goto statement to avoid the
>> memory leak in inline extents case.
>>
>> Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in 
>> range_is_hole_in_parent()")
> 
> With the commit message fixed it looks good to me.
> 
>> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
>> ---
>>   fs/btrfs/send.c | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
>> index 6768e2231d61..b107a33dfd4d 100644
>> --- a/fs/btrfs/send.c
>> +++ b/fs/btrfs/send.c
>> @@ -6545,8 +6545,10 @@ static int range_is_hole_in_parent(struct 
>> send_ctx *sctx,
>>           extent_end = btrfs_file_extent_end(path);
>>           if (extent_end <= start)
>>               goto next;
>> -        if (btrfs_file_extent_type(leaf, fi) == 
>> BTRFS_FILE_EXTENT_INLINE)
>> -            return 0;
>> +        if (btrfs_file_extent_type(leaf, fi) == 
>> BTRFS_FILE_EXTENT_INLINE) {
>> +            ret = 0;
>> +            goto out;
>> +        }
>>           if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
>>               search_start = extent_end;
>>               goto next;
> 
> 

Re: [PATCH 6.6] btrfs: free path if inline extents in range_is_hole_in_parent()

[Hongbo Li]

Hi Wenruo,

On 2026/2/27 14:48, Qu Wenruo wrote:
> 
> 
> 在 2026/2/27 17:14, Hongbo Li 写道:
>> Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
>> range_is_hole_in_parent()") is a patch backported directly from
>> mainline to 6.6, it does not free the path in the inline extents case.
>>
>> Commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
>> conversions") in 6.18-rc1 fixes this by accident
> 
> It's not "by accident", it's the designed behavior, remember the fix is 
> after that commit introducing scope-based auto-cleanup.
> 
> It's missing the dependency, which can not be directly backported, and 
> considering the scope-based auto-cleanup makes is much harder to detect 
> just by the patch context, it's indeed a problem.

Thanks for quickly reviewing.

Yeah, you are right, the commit 08b096c1372c ("btrfs: send: check for 
inline extents in range_is_hole_in_parent()") is later. So I think I 
should update my commit message.

In addition, the 6.12 LTS may have the same problem which introduced by 
db00636643e66898d79f2530ac9c56ebd5eca369.

Thanks,
Hongbo

> 
>> by converting to
>> BTRFS_PATH_AUTO_FREE, but we cannot backport this to 6.6 due to many
>> dependencies. Instead, we choose to use a goto statement to avoid the
>> memory leak in inline extents case.
>>
>> Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in 
>> range_is_hole_in_parent()")
> 
> With the commit message fixed it looks good to me.
> 
>> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
>> ---
>>   fs/btrfs/send.c | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
>> index 6768e2231d61..b107a33dfd4d 100644
>> --- a/fs/btrfs/send.c
>> +++ b/fs/btrfs/send.c
>> @@ -6545,8 +6545,10 @@ static int range_is_hole_in_parent(struct 
>> send_ctx *sctx,
>>           extent_end = btrfs_file_extent_end(path);
>>           if (extent_end <= start)
>>               goto next;
>> -        if (btrfs_file_extent_type(leaf, fi) == 
>> BTRFS_FILE_EXTENT_INLINE)
>> -            return 0;
>> +        if (btrfs_file_extent_type(leaf, fi) == 
>> BTRFS_FILE_EXTENT_INLINE) {
>> +            ret = 0;
>> +            goto out;
>> +        }
>>           if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
>>               search_start = extent_end;
>>               goto next;
> 
> 

Re: [PATCH 6.6] btrfs: free path if inline extents in range_is_hole_in_parent()

[Qu Wenruo]

在 2026/2/27 17:46, Hongbo Li 写道:
> Hi Wenruo,
> 
> On 2026/2/27 14:48, Qu Wenruo wrote:
>>
>>
>> 在 2026/2/27 17:14, Hongbo Li 写道:
>>> Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
>>> range_is_hole_in_parent()") is a patch backported directly from
>>> mainline to 6.6, it does not free the path in the inline extents case.
>>>
>>> Commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
>>> conversions") in 6.18-rc1 fixes this by accident
>>
>> It's not "by accident", it's the designed behavior, remember the fix 
>> is after that commit introducing scope-based auto-cleanup.
>>
>> It's missing the dependency, which can not be directly backported, and 
>> considering the scope-based auto-cleanup makes is much harder to 
>> detect just by the patch context, it's indeed a problem.
> 
> Thanks for quickly reviewing.
> 
> Yeah, you are right, the commit 08b096c1372c ("btrfs: send: check for 
> inline extents in range_is_hole_in_parent()") is later. So I think I 
> should update my commit message.
> 
> In addition, the 6.12 LTS may have the same problem which introduced by 
> db00636643e66898d79f2530ac9c56ebd5eca369.

Yep, I also noticed this during my manual backport for SLE kernels and 
fixed them there, but didn't notice the auto-backport from stable branches.

BTW, 5.10.x got the problem noticed, but other branches didn't:

https://lore.kernel.org/stable/2026020514-oat-plant-b273@gregkh/


> 
> Thanks,
> Hongbo
> 
>>
>>> by converting to
>>> BTRFS_PATH_AUTO_FREE, but we cannot backport this to 6.6 due to many
>>> dependencies. Instead, we choose to use a goto statement to avoid the
>>> memory leak in inline extents case.
>>>
>>> Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in 
>>> range_is_hole_in_parent()")
>>
>> With the commit message fixed it looks good to me.
>>
>>> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
>>> ---
>>>   fs/btrfs/send.c | 6 ++++--
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
>>> index 6768e2231d61..b107a33dfd4d 100644
>>> --- a/fs/btrfs/send.c
>>> +++ b/fs/btrfs/send.c
>>> @@ -6545,8 +6545,10 @@ static int range_is_hole_in_parent(struct 
>>> send_ctx *sctx,
>>>           extent_end = btrfs_file_extent_end(path);
>>>           if (extent_end <= start)
>>>               goto next;
>>> -        if (btrfs_file_extent_type(leaf, fi) == 
>>> BTRFS_FILE_EXTENT_INLINE)
>>> -            return 0;
>>> +        if (btrfs_file_extent_type(leaf, fi) == 
>>> BTRFS_FILE_EXTENT_INLINE) {
>>> +            ret = 0;
>>> +            goto out;
>>> +        }
>>>           if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
>>>               search_start = extent_end;
>>>               goto next;
>>
>>

[PATCH 6.6 v2] btrfs: free path if inline extents in range_is_hole_in_parent()

[Hongbo Li]

Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
range_is_hole_in_parent()") is a patch backported directly from
mainline to 6.6, it does not free the path in the inline extents case.

The original patch in mainline does not have this problem because
the former commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
conversions") in 6.18-rc1 introduced scope-based auto-cleanup which
avoids this issue. Since some dependencies are missing and cannot
be directly backported, we choose to use a goto statement to avoid
the memory leak in inline extents case.

Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in range_is_hole_in_parent()")
Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
---
Changes since v1:
  - Update commit message as Wenruo pointed out.
  - Link to v1: https://lore.kernel.org/all/20260227064414.2314529-1-lihongbo22@huawei.com/
---
 fs/btrfs/send.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 6768e2231d61..b107a33dfd4d 100644
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -6545,8 +6545,10 @@ static int range_is_hole_in_parent(struct send_ctx *sctx,
 		extent_end = btrfs_file_extent_end(path);
 		if (extent_end <= start)
 			goto next;
-		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE)
-			return 0;
+		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
+			ret = 0;
+			goto out;
+		}
 		if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
 			search_start = extent_end;
 			goto next;
-- 
2.34.1

Re: [PATCH 6.6 v2] btrfs: free path if inline extents in range_is_hole_in_parent()

[Qu Wenruo]

在 2026/2/27 18:22, Hongbo Li 写道:
> Commit f2dc6ab3a14c ("btrfs: send: check for inline extents in
> range_is_hole_in_parent()") is a patch backported directly from
> mainline to 6.6, it does not free the path in the inline extents case.
> 
> The original patch in mainline does not have this problem because
> the former commit 4ca6f24a52c4 ("btrfs: more trivial BTRFS_PATH_AUTO_FREE
> conversions") in 6.18-rc1 introduced scope-based auto-cleanup which
> avoids this issue. Since some dependencies are missing and cannot
> be directly backported, we choose to use a goto statement to avoid
> the memory leak in inline extents case.
> 
> Fixes: f2dc6ab3a14c ("btrfs: send: check for inline extents in range_is_hole_in_parent()")
> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>

Reviewed-by: Qu Wenruo <wqu@suse.com>

Thanks,
Qu

> ---
> Changes since v1:
>    - Update commit message as Wenruo pointed out.
>    - Link to v1: https://lore.kernel.org/all/20260227064414.2314529-1-lihongbo22@huawei.com/
> ---
>   fs/btrfs/send.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
> index 6768e2231d61..b107a33dfd4d 100644
> --- a/fs/btrfs/send.c
> +++ b/fs/btrfs/send.c
> @@ -6545,8 +6545,10 @@ static int range_is_hole_in_parent(struct send_ctx *sctx,
>   		extent_end = btrfs_file_extent_end(path);
>   		if (extent_end <= start)
>   			goto next;
> -		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE)
> -			return 0;
> +		if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
> +			ret = 0;
> +			goto out;
> +		}
>   		if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
>   			search_start = extent_end;
>   			goto next;

Re: [PATCH 6.6 v2] btrfs: free path if inline extents in range_is_hole_in_parent()

[kernel test robot]

Hi Hongbo,

kernel test robot noticed the following build errors:

[auto build test ERROR on v7.0-rc1]
[also build test ERROR on linus/master next-20260227]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Hongbo-Li/btrfs-free-path-if-inline-extents-in-range_is_hole_in_parent/20260227-155544
base:   v7.0-rc1
patch link:    https://lore.kernel.org/r/20260227075219.2594937-1-lihongbo22%40huawei.com
patch subject: [PATCH 6.6 v2] btrfs: free path if inline extents in range_is_hole_in_parent()
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260301/202603012047.GqC1IRml-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260301/202603012047.GqC1IRml-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603012047.GqC1IRml-lkp@intel.com/

All errors (new ones prefixed by >>):

>> fs/btrfs/send.c:6388:9: error: use of undeclared label 'out'
    6388 |                         goto out;
         |                              ^
   1 error generated.


vim +/out +6388 fs/btrfs/send.c

  6334	
  6335	static int range_is_hole_in_parent(struct send_ctx *sctx,
  6336					   const u64 start,
  6337					   const u64 end)
  6338	{
  6339		BTRFS_PATH_AUTO_FREE(path);
  6340		struct btrfs_key key;
  6341		struct btrfs_root *root = sctx->parent_root;
  6342		u64 search_start = start;
  6343		int ret;
  6344	
  6345		path = alloc_path_for_send();
  6346		if (!path)
  6347			return -ENOMEM;
  6348	
  6349		key.objectid = sctx->cur_ino;
  6350		key.type = BTRFS_EXTENT_DATA_KEY;
  6351		key.offset = search_start;
  6352		ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
  6353		if (ret < 0)
  6354			return ret;
  6355		if (ret > 0 && path->slots[0] > 0)
  6356			path->slots[0]--;
  6357	
  6358		while (search_start < end) {
  6359			struct extent_buffer *leaf = path->nodes[0];
  6360			int slot = path->slots[0];
  6361			struct btrfs_file_extent_item *fi;
  6362			u64 extent_end;
  6363	
  6364			if (slot >= btrfs_header_nritems(leaf)) {
  6365				ret = btrfs_next_leaf(root, path);
  6366				if (ret < 0)
  6367					return ret;
  6368				if (ret > 0)
  6369					break;
  6370				continue;
  6371			}
  6372	
  6373			btrfs_item_key_to_cpu(leaf, &key, slot);
  6374			if (key.objectid < sctx->cur_ino ||
  6375			    key.type < BTRFS_EXTENT_DATA_KEY)
  6376				goto next;
  6377			if (key.objectid > sctx->cur_ino ||
  6378			    key.type > BTRFS_EXTENT_DATA_KEY ||
  6379			    key.offset >= end)
  6380				break;
  6381	
  6382			fi = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item);
  6383			extent_end = btrfs_file_extent_end(path);
  6384			if (extent_end <= start)
  6385				goto next;
  6386			if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
  6387				ret = 0;
> 6388				goto out;
  6389			}
  6390			if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
  6391				search_start = extent_end;
  6392				goto next;
  6393			}
  6394			return 0;
  6395	next:
  6396			path->slots[0]++;
  6397		}
  6398		return 1;
  6399	}
  6400	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 6.6 v2] btrfs: free path if inline extents in range_is_hole_in_parent()

[Qu Wenruo]

在 2026/3/1 23:01, kernel test robot 写道:
> Hi Hongbo,
> 
> kernel test robot noticed the following build errors:
> 
> [auto build test ERROR on v7.0-rc1]

Wrong branch.

The patch has 6.6 in its subjective line, it's only for v6.6 kernel.

Thanks,
Qu

> [also build test ERROR on linus/master next-20260227]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Hongbo-Li/btrfs-free-path-if-inline-extents-in-range_is_hole_in_parent/20260227-155544
> base:   v7.0-rc1
> patch link:    https://lore.kernel.org/r/20260227075219.2594937-1-lihongbo22%40huawei.com
> patch subject: [PATCH 6.6 v2] btrfs: free path if inline extents in range_is_hole_in_parent()
> config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260301/202603012047.GqC1IRml-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260301/202603012047.GqC1IRml-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202603012047.GqC1IRml-lkp@intel.com/
> 
> All errors (new ones prefixed by >>):
> 
>>> fs/btrfs/send.c:6388:9: error: use of undeclared label 'out'
>      6388 |                         goto out;
>           |                              ^
>     1 error generated.
> 
> 
> vim +/out +6388 fs/btrfs/send.c
> 
>    6334	
>    6335	static int range_is_hole_in_parent(struct send_ctx *sctx,
>    6336					   const u64 start,
>    6337					   const u64 end)
>    6338	{
>    6339		BTRFS_PATH_AUTO_FREE(path);
>    6340		struct btrfs_key key;
>    6341		struct btrfs_root *root = sctx->parent_root;
>    6342		u64 search_start = start;
>    6343		int ret;
>    6344	
>    6345		path = alloc_path_for_send();
>    6346		if (!path)
>    6347			return -ENOMEM;
>    6348	
>    6349		key.objectid = sctx->cur_ino;
>    6350		key.type = BTRFS_EXTENT_DATA_KEY;
>    6351		key.offset = search_start;
>    6352		ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
>    6353		if (ret < 0)
>    6354			return ret;
>    6355		if (ret > 0 && path->slots[0] > 0)
>    6356			path->slots[0]--;
>    6357	
>    6358		while (search_start < end) {
>    6359			struct extent_buffer *leaf = path->nodes[0];
>    6360			int slot = path->slots[0];
>    6361			struct btrfs_file_extent_item *fi;
>    6362			u64 extent_end;
>    6363	
>    6364			if (slot >= btrfs_header_nritems(leaf)) {
>    6365				ret = btrfs_next_leaf(root, path);
>    6366				if (ret < 0)
>    6367					return ret;
>    6368				if (ret > 0)
>    6369					break;
>    6370				continue;
>    6371			}
>    6372	
>    6373			btrfs_item_key_to_cpu(leaf, &key, slot);
>    6374			if (key.objectid < sctx->cur_ino ||
>    6375			    key.type < BTRFS_EXTENT_DATA_KEY)
>    6376				goto next;
>    6377			if (key.objectid > sctx->cur_ino ||
>    6378			    key.type > BTRFS_EXTENT_DATA_KEY ||
>    6379			    key.offset >= end)
>    6380				break;
>    6381	
>    6382			fi = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item);
>    6383			extent_end = btrfs_file_extent_end(path);
>    6384			if (extent_end <= start)
>    6385				goto next;
>    6386			if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
>    6387				ret = 0;
>> 6388				goto out;
>    6389			}
>    6390			if (btrfs_file_extent_disk_bytenr(leaf, fi) == 0) {
>    6391				search_start = extent_end;
>    6392				goto next;
>    6393			}
>    6394			return 0;
>    6395	next:
>    6396			path->slots[0]++;
>    6397		}
>    6398		return 1;
>    6399	}
>    6400	
>