[PATCH v2 0/1] vfs: add FILE_DEDUPE_RANGE_REPORT_PROGRESS flag to FIDEDUPERANGE

[Matthias Goergens <matthias.goergens@gmail.com>]

Changes since v1 (<20260805071414.3414870-1-matthias.goergens@gmail.com>):

Darrick is right that bytes_deduped = len predates the VFS hoisting -
the manpage describes the behaviour the patch would introduce, not the
historical default, and deployed consumers (duperemove advances file
offsets by bytes_deduped) depend on the old semantics.  v2 therefore
keeps the default unchanged and gates the truthful behaviour behind a
new flag:

- FILE_DEDUPE_RANGE_REPORT_PROGRESS (the former reserved2 field is now
  flags): bytes_deduped reports the bytes actually deduplicated, and a
  non-zero request shortened to zero fails per destination with -EINVAL
  instead of reporting success with no progress.
- Unknown flag bits are rejected with -EINVAL.

The fstests series will follow in the same shape: the generic/517
golden output stays as it is (unflagged behaviour is unchanged), and
the new test exercises the flag, including one unflagged case pinning
the legacy reporting.

Darrick also notes the manpage is wrong - with the flag in place, the
right fix is to document the flag in ioctl_fideduperange(2) rather than
change the default; a man-pages patch can follow once the flag name and
semantics are settled.

Amir: you reviewed the v1 logic favourably - could you have a look at
the flag shape instead?  In particular: the name
(FILE_DEDUPE_RANGE_REPORT_PROGRESS), the semantics (actual bytes plus
-EINVAL on zero progress), and whether the manpage fix should ride
along with the kernel patch or follow separately.  If this shape works
for you, the Reviewed-by on the flagged behaviour would be very
welcome.