From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:51589 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932411AbcFCPnc (ORCPT ); Fri, 3 Jun 2016 11:43:32 -0400 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 30B76AC71 for ; Fri, 3 Jun 2016 15:43:31 +0000 (UTC) From: David Sterba To: stable@vger.kernel.org Subject: [PATCH 19/21] Btrfs: fix unexpected return value of fiemap Date: Fri, 3 Jun 2016 17:42:49 +0200 Message-Id: <1464968569-7043-1-git-send-email-dsterba@suse.com> In-Reply-To: <20160603154006.GP29147@suse.cz> References: <20160603154006.GP29147@suse.cz> Sender: stable-owner@vger.kernel.org List-ID: From: Liu Bo commit 2d324f59f343967a03eeb2690f0ff178304d0687 upstream. 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: btrfs_lookup_file_extent -> btrfs_search_slot(..., ins_len=0, cow=0) and if the offset is beyond EOF, we'll get 'path' pointed to the place of potentail insertion, and ret == 1. This may confuse applications using ioctl(FIEL_IOC_FIEMAP). Signed-off-by: Liu Bo Signed-off-by: David Sterba --- 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 392592dc7010..57fccc420697 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -4385,8 +4385,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; } - WARN_ON(!ret); + path->slots[0]--; btrfs_item_key_to_cpu(path->nodes[0], &found_key, path->slots[0]); found_type = found_key.type; -- 2.7.1