Page MenuHomeFreeBSD

copy_file_range: truncate write if it would exceed RLIMIT_FSIZE
ClosedPublic

Authored by asomers on Sep 25 2022, 11:17 PM.

Details

Summary

copy_file_range: truncate write if it would exceed RLIMIT_FSIZE

PR: 266611
MFC after: 2 weeks

Test Plan

test case added for fusefs. Manual testing for UFS, ZFS, tmpfs, msdosfs, and nfs.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Use of vn_rlimit_fsizex() requires finishing VOP with vn_rlimit_fsizex_res().
It is strange for nfs to obey new behavior for vop copy_range, but not for write (I did not converted nfs).

In D36706#833361, @kib wrote:

Use of vn_rlimit_fsizex() requires finishing VOP with vn_rlimit_fsizex_res().

That's only so the caller will see the correct value of uio_resid, right? For VOP_COPY_FILE_RANGE, the caller does not provide a struct uio. Instead, it's only necessary to return the number of bytes copied in *ap->a_lenp , AFAICT.

It is strange for nfs to obey new behavior for vop copy_range, but not for write (I did not converted nfs).

I could try to fix that one too.

In D36706#833361, @kib wrote:

Use of vn_rlimit_fsizex() requires finishing VOP with vn_rlimit_fsizex_res().

That's only so the caller will see the correct value of uio_resid, right? For VOP_COPY_FILE_RANGE, the caller does not provide a struct uio. Instead, it's only necessary to return the number of bytes copied in *ap->a_lenp , AFAICT.

Right now yes, but I considered it the current implementation detail. At least please add a comment explaining why _res() is not called, but I consider it fragile.

  • Add comments about vn_rlimit_fsizex_res
This revision is now accepted and ready to land.Sep 26 2022, 11:01 AM