linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: linux-fsdevel@vger.kernel.org
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: [PATCH 3/3] zonefs: fix zonefs_iomap_begin() for reads
Date: Fri,  3 Jun 2022 20:49:39 +0900	[thread overview]
Message-ID: <20220603114939.236783-4-damien.lemoal@opensource.wdc.com> (raw)
In-Reply-To: <20220603114939.236783-1-damien.lemoal@opensource.wdc.com>

If a read operation (e.g. a readahead) is issued to a sequential zone
file with an offset exactly equal to the current file size, the iomap
type will be set to IOMAP_UNWRITTEN, which will prevent an IO, but the
iomap length is always calculated as 0. This causes a WARN_ON() in
iomap_iter():

[17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80
[...]
[17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80
[...]
[17309.754560] Call Trace:
[17309.757078]  <TASK>
[17309.759240]  ? lock_is_held_type+0xd8/0x130
[17309.763531]  iomap_readahead+0x1a8/0x870
[17309.767550]  ? iomap_read_folio+0x4c0/0x4c0
[17309.771817]  ? lockdep_hardirqs_on_prepare+0x400/0x400
[17309.778848]  ? lock_release+0x370/0x750
[17309.784462]  ? folio_add_lru+0x217/0x3f0
[17309.790220]  ? reacquire_held_locks+0x4e0/0x4e0
[17309.796543]  read_pages+0x17d/0xb60
[17309.801854]  ? folio_add_lru+0x238/0x3f0
[17309.807573]  ? readahead_expand+0x5f0/0x5f0
[17309.813554]  ? policy_node+0xb5/0x140
[17309.819018]  page_cache_ra_unbounded+0x27d/0x450
[17309.825439]  filemap_get_pages+0x500/0x1450
[17309.831444]  ? filemap_add_folio+0x140/0x140
[17309.837519]  ? lock_is_held_type+0xd8/0x130
[17309.843509]  filemap_read+0x28c/0x9f0
[17309.848953]  ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs]
[17309.856162]  ? trace_contention_end+0xd6/0x130
[17309.862416]  ? __mutex_lock+0x221/0x1480
[17309.868151]  ? zonefs_file_read_iter+0x166/0x4d0 [zonefs]
[17309.875364]  ? filemap_get_pages+0x1450/0x1450
[17309.881647]  ? __mutex_unlock_slowpath+0x15e/0x620
[17309.888248]  ? wait_for_completion_io_timeout+0x20/0x20
[17309.895231]  ? lock_is_held_type+0xd8/0x130
[17309.901115]  ? lock_is_held_type+0xd8/0x130
[17309.906934]  zonefs_file_read_iter+0x356/0x4d0 [zonefs]
[17309.913750]  new_sync_read+0x2d8/0x520
[17309.919035]  ? __x64_sys_lseek+0x1d0/0x1d0

Furthermore, this causes iomap_readahead() to loop forever as
iomap_readahead_iter() always return 0, making no progress.

Fix this by avoiding that the iomap length be calculated as 0 by not
modifying the original length argument passed to zonefs_iomap_begin().

Reported-by: Jorgen Hansen <Jorgen.Hansen@wdc.com>
Fixes: 8dcc1a9d90c1 ("fs: New zonefs file system")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
---
 fs/zonefs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/zonefs/super.c b/fs/zonefs/super.c
index 123464d2145a..64f4ceb6f579 100644
--- a/fs/zonefs/super.c
+++ b/fs/zonefs/super.c
@@ -144,7 +144,7 @@ static int zonefs_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
 		iomap->type = IOMAP_MAPPED;
 	if (flags & IOMAP_WRITE)
 		length = zi->i_max_size - offset;
-	else
+	else if (offset < isize)
 		length = min(length, isize - offset);
 	mutex_unlock(&zi->i_truncate_mutex);
 
-- 
2.36.1


  parent reply	other threads:[~2022-06-03 11:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 11:49 [PATCH 0/3] zonefs fixes Damien Le Moal
2022-06-03 11:49 ` [PATCH 1/3] zonefs: fix handling of explicit_open option on mount Damien Le Moal
2022-06-07  6:01   ` Christoph Hellwig
2022-06-07  8:46   ` Johannes Thumshirn
2022-06-03 11:49 ` [PATCH 2/3] zonefs: Do not ignore explicit_open with active zone limit Damien Le Moal
2022-06-07  6:02   ` Christoph Hellwig
2022-06-03 11:49 ` Damien Le Moal [this message]
2022-06-07  6:09   ` [PATCH 3/3] zonefs: fix zonefs_iomap_begin() for reads Christoph Hellwig
2022-06-07  6:53     ` Damien Le Moal
2022-06-07 10:09       ` Christoph Hellwig
2022-06-07 10:25         ` Damien Le Moal

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=20220603114939.236783-4-damien.lemoal@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-fsdevel@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).