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@xxxxxxxxxx> 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
