On Tue, May 17, 2016 at 05:21:48PM -0700, Liu Bo wrote:
> btrfs's fiemap is supposed to return 0 on success and
> return < 0 on error, however, ret becomes 1 after looking
> up the last file extent, and if the offset is beyond EOF,
> we can return 1.
>
> This may confuse applications using ioctl(FIEL_IOC_FIEMAP).
>
> Signed-off-by: Liu Bo <bo.li.liu@xxxxxxxxxx>
Reviewed-by: David Sterba <dsterba@xxxxxxxx>
> ---
> fs/btrfs/extent_io.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index d247fc0..16ece52 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -4379,8 +4379,12 @@ int extent_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo,
> if (ret < 0) {
> btrfs_free_path(path);
> return ret;
> + } else {
> + WARN_ON(!ret);
> + if (ret == 1)
> + ret = 0;
> }
So, ret == 1 can end up here from btrfs_lookup_file_extent ->
btrfs_search_slot(..., ins_len=0, cow=0) and the offset does not exist,
we'll get path pointed to the slot where it would be inserted and ret is 1.
--
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
