All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-mm@kvack.org
Subject: [PATCH] filemap: skip range writeback if end offset precedes start
Date: Fri, 28 Oct 2022 08:54:28 -0400	[thread overview]
Message-ID: <20221028125428.976549-1-bfoster@redhat.com> (raw)

A call to file[map]_write_and_wait_range() with an end offset that
precedes the start offset but happens to land in the same page can
trigger writeback submission but fail to wait on the submitted page.
Writeback submission occurs because __filemap_fdatawrite_range()
passes both offsets down into write_cache_pages(), which rounds down
to page indexes before it starts processing writeback.
__filemap_fdatawait_range() immediately returns if the specified end
offset precedes the start offset, however.

I suspect these checks are primarily intended to handle overflow
conditions. I happened to notice this behavior when investigating an
unrelated problem and observed that a filemap_write_and_wait_range()
call with unexpected parameters had seemingly unpredictable latency.
That latency turned out to be the submission path occasionally
waiting on writeback state of the page (i.e. from
write_cache_pages()) before issuing the currently requested
writepage and then unconditionally failing to wait on the latter via
__filemap_fdatawait_range().

This could probably be reasonably fixed to either elide the
submission, as this patch does, or modify the fdatawait path to
check the page indexes instead of the unaligned offsets. After
poking around a bit, it seemed more consistent with various other
filemap interfaces to check the offsets in the write path and return
if the end offset is not >= the start. For example,
filemap_range_has_page() and filemap_range_has_writeback() both
include similar byte granularity checks.

Signed-off-by: Brian Foster <bfoster@redhat.com>
---
 mm/filemap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/filemap.c b/mm/filemap.c
index 08341616ae7a..99d8686c9f5c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -418,6 +418,9 @@ int __filemap_fdatawrite_range(struct address_space *mapping, loff_t start,
 		.range_end = end,
 	};
 
+	if (end < start)
+		return 0;
+
 	return filemap_fdatawrite_wbc(mapping, &wbc);
 }
 
-- 
2.37.3



             reply	other threads:[~2022-10-28 12:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-28 12:54 Brian Foster [this message]
2022-10-31  4:51 ` [PATCH] filemap: skip range writeback if end offset precedes start Andrew Morton
2022-11-07 16:33   ` Brian Foster
2022-11-07 20:28     ` Andrew Morton
2022-11-14 17:35       ` Brian Foster

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=20221028125428.976549-1-bfoster@redhat.com \
    --to=bfoster@redhat.com \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.