From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, David Sterba <dsterba@suse.cz>,
Adam Borowski <kilobyte@angband.pl>,
Qu Wenruo <quwenruo@cn.fujitsu.com>,
David Sterba <dsterba@suse.com>
Subject: [PATCH 4.9 17/20] btrfs: Remove false alert when fiemap range is smaller than on-disk extent
Date: Thu, 21 Feb 2019 15:35:55 +0100 [thread overview]
Message-ID: <20190221125244.027806070@linuxfoundation.org> (raw)
In-Reply-To: <20190221125242.153179182@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
commit 848c23b78fafdcd3270b06a30737f8dbd70c347f upstream.
Commit 4751832da990 ("btrfs: fiemap: Cache and merge fiemap extent before
submit it to user") introduced a warning to catch unemitted cached
fiemap extent.
However such warning doesn't take the following case into consideration:
0 4K 8K
|<---- fiemap range --->|
|<----------- On-disk extent ------------------>|
In this case, the whole 0~8K is cached, and since it's larger than
fiemap range, it break the fiemap extent emit loop.
This leaves the fiemap extent cached but not emitted, and caught by the
final fiemap extent sanity check, causing kernel warning.
This patch removes the kernel warning and renames the sanity check to
emit_last_fiemap_cache() since it's possible and valid to have cached
fiemap extent.
Reported-by: David Sterba <dsterba@suse.cz>
Reported-by: Adam Borowski <kilobyte@angband.pl>
Fixes: 4751832da990 ("btrfs: fiemap: Cache and merge fiemap extent ...")
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/extent_io.c | 28 ++++++++++++----------------
1 file changed, 12 insertions(+), 16 deletions(-)
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -4463,29 +4463,25 @@ try_submit_last:
}
/*
- * Sanity check for fiemap cache
+ * Emit last fiemap cache
*
- * All fiemap cache should be submitted by emit_fiemap_extent()
- * Iteration should be terminated either by last fiemap extent or
- * fieinfo->fi_extents_max.
- * So no cached fiemap should exist.
+ * The last fiemap cache may still be cached in the following case:
+ * 0 4k 8k
+ * |<- Fiemap range ->|
+ * |<------------ First extent ----------->|
+ *
+ * In this case, the first extent range will be cached but not emitted.
+ * So we must emit it before ending extent_fiemap().
*/
-static int check_fiemap_cache(struct btrfs_fs_info *fs_info,
- struct fiemap_extent_info *fieinfo,
- struct fiemap_cache *cache)
+static int emit_last_fiemap_cache(struct btrfs_fs_info *fs_info,
+ struct fiemap_extent_info *fieinfo,
+ struct fiemap_cache *cache)
{
int ret;
if (!cache->cached)
return 0;
- /* Small and recoverbale problem, only to info developer */
-#ifdef CONFIG_BTRFS_DEBUG
- WARN_ON(1);
-#endif
- btrfs_warn(fs_info,
- "unhandled fiemap cache detected: offset=%llu phys=%llu len=%llu flags=0x%x",
- cache->offset, cache->phys, cache->len, cache->flags);
ret = fiemap_fill_next_extent(fieinfo, cache->offset, cache->phys,
cache->len, cache->flags);
cache->cached = false;
@@ -4701,7 +4697,7 @@ int extent_fiemap(struct inode *inode, s
}
out_free:
if (!ret)
- ret = check_fiemap_cache(root->fs_info, fieinfo, &cache);
+ ret = emit_last_fiemap_cache(root->fs_info, fieinfo, &cache);
free_extent_map(em);
out:
btrfs_free_path(path);
next prev parent reply other threads:[~2019-02-21 14:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 14:35 [PATCH 4.9 00/20] 4.9.160-stable review Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 01/20] net: fix IPv6 prefix route residue Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 02/20] vsock: cope with memory allocation failure at socket creation time Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 03/20] hwmon: (lm80) Fix missing unlock on error in set_fan_div() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 04/20] net: Fix for_each_netdev_feature on Big endian Greg Kroah-Hartman
2019-02-21 17:26 ` Mehrtens, Hauke
2019-02-21 19:13 ` Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 05/20] net: phy: xgmiitorgmii: Support generic PHY status read Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 06/20] net: stmmac: handle endianness in dwmac4_get_timestamp Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 07/20] net: validate untrusted gso packets without csum offload Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 08/20] sky2: Increase D3 delay again Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 09/20] vhost: correctly check the return value of translate_desc() in log_used() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 10/20] net: Add header for usage of fls64() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 11/20] tcp: tcp_v4_err() should be more careful Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 12/20] net: Do not allocate page fragments that are not skb aligned Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 13/20] tcp: clear icsk_backoff in tcp_write_queue_purge() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 14/20] vxlan: test dev->flags & IFF_UP before calling netif_rx() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 15/20] net: stmmac: Fix a race in EEE enable callback Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 16/20] net: ipv4: use a dedicated counter for icmp_v4 redirect packets Greg Kroah-Hartman
2019-02-21 14:35 ` Greg Kroah-Hartman [this message]
2019-02-21 14:35 ` [PATCH 4.9 18/20] net/x25: do not hold the cpu too long in x25_new_lci() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 19/20] mISDN: fix a race in dev_expire_timer() Greg Kroah-Hartman
2019-02-21 14:35 ` [PATCH 4.9 20/20] ax25: fix possible use-after-free Greg Kroah-Hartman
2019-02-21 18:19 ` [PATCH 4.9 00/20] 4.9.160-stable review kernelci.org bot
2019-02-22 2:35 ` Naresh Kamboju
2019-02-22 8:13 ` Jon Hunter
2019-02-22 23:03 ` shuah
2019-02-22 23:31 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190221125244.027806070@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=kilobyte@angband.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).