Hi all, Here's a v2 of a prospective fix for the odd write and wait behavior described in the patch 1 commit log. Technically patch 1 could simply remove the check rather than lift it into the callers, but this seemed a bit more user friendly to me. Patch 2 is appended after observation that fadvise() interacted poorly with the v1 patch. This is no longer a problem with v2, making patch 2 purely a cleanup. This series survived both fstests and ltp regression runs without observable problems. I had (end < start) warning checks in each relevant function, with fadvise() being the only caller that triggered them. That said, I dropped the warnings after testing because there seemed to much potential for noise from the various other callers. Brian v2: - Remove check from fdatawait rather than add to fdatawrite (as in v1). Lift into file[map]_write_and_wait_range() helpers. - Added patch 2. v1: https://lore.kernel.org/linux-mm/20221028125428.976549-1-bfoster@xxxxxxxxxx/ Brian Foster (2): filemap: skip write and wait if end offset precedes start mm/fadvise: use LLONG_MAX instead of -1 for eof mm/fadvise.c | 2 +- mm/filemap.c | 9 ++++++--- 2 files changed, 7 insertions(+), 4 deletions(-) -- 2.37.3
