On Wed, 20 Aug 2025 at 07:20, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > I don't understand the current behavior at all -- why do the callers of > fuse_writeback_range pass an @end parameter when it ignores @end in > favor of LLONG_MAX? And why is it necessary to flush to EOF at all? > fallocate and copy_file_range both take i_rwsem, so what could they be > racing with? Or am I missing something here? commit 59bda8ecee2f ("fuse: flush extending writes") The issue AFAICS is that if writes beyond the range end are not flushed, then EOF on backing file could be below range end (if pending writes create a hole), hence copy_file_range() will stop copying at the start of that hole. So this patch is incorrect, since not flushing copy_file_range input file could result in a short copy. Thanks, Miklos