Re: [PATCH] filemap: skip range writeback if end offset precedes start

[Brian Foster <bfoster@redhat.com>]

On Mon, Nov 07, 2022 at 12:28:02PM -0800, Andrew Morton wrote:
> On Mon, 7 Nov 2022 11:33:46 -0500 Brian Foster <bfoster@redhat.com> wrote:
> 
> > Perhaps a good starting point would be to wrap the check in
> > this patch with a WARN_ON_ONCE() and let it soak in -next for a while?
> > That would avoid excessive noise from repetitive callers [1] but still
> > allow those callsites to be identified/fixed. If there is some really
> > weird fdatawrite-only caller that conflicts, the change could always be
> > loosened up from there (as unlikely as that seems).. Hm?
> 
> Sounds reasonable.
> 
> Please let's be clear in the changelog why we're adding this.  I mean,
> we could add a zillion checks everywhere for misbehaving callers.  Why
> choose this one place in particular?
> 

Ok, so TLDR.. this patch is broken as is. I was probably thinking the
generic_fadvise() case of end == -1 was cast to unsigned by the caller,
but testing shows that is not the case and -1 is passed down as a valid
input. This obviously conflicts with the check as proposed here.

I suppose it might make some sense to drop the analogous check from
__filemap_fdatawait_range() so underlying write/wait behavior is
consistent, and perhaps consider adding a higher level check in the
write_and_wait_range() wrappers. I'd have to make a pass through some of
the callers and think about that some more. I.e.,
filemap_write_and_wait_range() documents that end = -1 is acceptable,
fdatawrite presumably does the right thing in that case, fdatawait skips
when end_byte < start_byte, and most callers seem to actually use
LLONG_MAX anyways.

Brian