When a write() cannot transfer as many bytes as requested (because of a file limit), it fails instead of transferring as many bytes as there is room to write. This is a violation of the POSIX standard: http://pubs.opengroup.org/onlinepubs/007904975/functions/write.html Fix: Patch attached with submission follows: How-To-Repeat: fsize-lim.c.txt (attached) illustrates the problem. With a freebsd kernel, the output is: failed when adding 27 bytes after 59994 bytes (error: File too large) The expected output (like with a linux kernel) should be: added 6 bytes instead of 27 bytes after 59994 bytes failed when adding 27 bytes after 60000 bytes (error: File too large)
On Sun, 5 Feb 2012, Nicolas Bourdaud wrote: >> Description: > When a write() cannot transfer as many bytes as requested (because of a file > limit), it fails instead of transferring as many bytes as there is room to > write. > > This is a violation of the POSIX standard: > http://pubs.opengroup.org/onlinepubs/007904975/functions/write.html FreeBSD's handling of the maxfilesize limits is similar, so it has the same bug. This affects many fileystems which copied the buggy code from ffs. (Both truncate() and write() fail if extending to or writing the full number of bytes would exceed the limit. This is correct for truncate(), but write() is required to creep up on the limit.) I think this is actually a bug in POSIX (XSI). Most programs aren't prepared to deal with short writes, and returning an error like truncate() is specified to is adequate. For regular files, most file systems in FreeBSD back out of writes after an i/o error, using ftruncate() (some truncation is necessary for security, since the place at which the error occurred is usually not known precisely), so the following bug in the upper layer rarely matters. From an old version of sys_generic.c, for writing (reading has a similar bug): % if ((error = fo_write(fp, &auio, td->td_ucred, flags, td))) { % /* XXX short write botch. */ % if (auio.uio_resid != cnt && (error == ERESTART || % error == EINTR || error == EWOULDBLOCK)) % error = 0; The XXX comment is only in my version. Here (auio.uio_resid != cnt) means that some i/o was done. In that case, write() is required to return the amount done, with no error, which is implemented by setting `error' to 0. But this is only done if `error' is one of ERESTART, EINTR or EWOULDBLOCK. At least the case of the most common error that is not one of these, namely EIO, is broken. The handling of the special 3 here is delicate: - ERESTART: hopefully can't happen, since if it happens then we should restart. This error is a non-error that in most cases means that the we handled a signal but are not returning with EINTR because SA_RESTART says to restart instead of returning. - EINTR: since we have this and not ERESTART, it is clearly correct to return, but if we did some i/o then we must return its amount and there is no way to return EINTR. - EWOULDBLOCK: similar to EINTR for a SIGALRM, but more precise. I guess this is here since it is the only other common error, and it is not really an error so failing for it would be obviously wrong (except when no i/o was done, EWOULDBLOCK = EAGAIN is the standard way to indicate this). The flag that controls backing out of writes is IO_UNIT. This is always set for write(2), and probably should be set unconditionally (so it shouldn't exist), since not setting it mainly asks for security holes and most cases are write(2) anyway. IO_UNIT means that the i/o is done as an "atomic unit". The semantics of "unit" probably includes doing all of it or none of it, so it would have to be broken to match the POSIX spec. > > ... > int main(void) > { > struct rlimit lim; > int fd; > ssize_t retc; > size_t count = 0; > const char pattern[PATTSIZE] = "Hello world!"; > > signal(SIGXFSZ, SIG_IGN); > lim.rlim_cur = LIMSIZE; > setrlimit(RLIMIT_FSIZE, &lim); This is missing initialization of at least lim.rlim_max in lim. This gave the bizarre behaviour that when the program was statically linked, it failed for the first write, because the stack garbage for lim.rlim_max happened to be 0. Bruce
On 05/02/2012 19:54, Bruce Evans wrote: > I think this is actually a bug in POSIX (XSI). Most programs aren't > prepared to deal with short writes, and returning an error like > truncate() is specified to is adequate. I disagree, I think that most programs that check that the write succeeded also check that the write was complete. Actually it was because my programs were assuming the POSIX behavior that I notice the bug. In addition, I think (this must be confirmed) that the bug don't affect the version 8.2... So the programs are already facing the POSIX behavior. Moreover the programs that are cross platform (in particular ported to Linux) are already facing this behavior. Whatever is decided, either freebsd should conform to the POSIX standard, either the standard should be changed. >> Patch attached with submission follows: >> ... >> int main(void) >> { >> struct rlimit lim; >> int fd; >> ssize_t retc; >> size_t count = 0; >> const char pattern[PATTSIZE] = "Hello world!"; >> >> signal(SIGXFSZ, SIG_IGN); >> lim.rlim_cur = LIMSIZE; >> setrlimit(RLIMIT_FSIZE, &lim); > > This is missing initialization of at least lim.rlim_max in lim. This > gave the bizarre behaviour that when the program was statically linked, > it failed for the first write, because the stack garbage for > lim.rlim_max happened to be 0. Yes I forgot one line: getrlimit(RLIMIT_FSIZE, &lim); just before "lim.rlim_cur = LIMSIZE;" Best regards Nicolas
On Wed, 15 Feb 2012, Nicolas Bourdaud wrote: > On 05/02/2012 19:54, Bruce Evans wrote: >> I think this is actually a bug in POSIX (XSI). Most programs aren't >> prepared to deal with short writes, and returning an error like >> truncate() is specified to is adequate. > > I disagree, I think that most programs that check that the write > succeeded also check that the write was complete. Actually it was Well, in BSD, programs that don't understand short writes start with the cp utility in 4.4BSD (it checks for short writes, but then mishandles them by treating them as errors). This wasn't fixed in FreeBSD until 1998. > because my programs were assuming the POSIX behavior that I notice the > bug. In addition, I think (this must be confirmed) that the bug don't > affect the version 8.2... So the programs are already facing the POSIX No, it was in 4.4BSD, and hasn't been changed in FreeBSD since 1994. 8.2 only differs in having the check in all file systems instead of in vfs. Perhaps some file systems got it right, but ffs didn't. > behavior. Moreover the programs that are cross platform (in particular > ported to Linux) are already facing this behavior. > > Whatever is decided, either freebsd should conform to the POSIX > standard, either the standard should be changed. It must conform, since it is too late to fix standards. I forgot about this when I looked at ffs's handling of i/o errors recently. There are many more bugs. ffs normally tries to back out of writes completely after an i/o error, by using ftruncate() to return to the original file size. Garbage written to the disk or memory is too hard to back out of, but ffs avoids security holes by zeroing it memory (in case it is memmap()ed) and by making it inaccessible by normal means on the disk (ftruncate() does this. When the error is ENOSPC due to a full disk, this gives the same behaviour as ffs has now for EFBIG for the file size being too big (due to the maximum size for the file system, or the rlimit). POSIX has looser wording for the ENOSPC error. It says that ENOSPC shall be returned if there "was" no space... This can be interpreted as requiring the same things as EFBIG -- that if there was any space to begin with, ENOSPC is not required to be returned; presumably the write() should succeed in writing as much as possible since there is no other reasonable error. But ffs's behaviour is "correct" here. The most broken case here is for an i/o error for a write in the middle of a file. Then it is not reasonable to try to back out. ffs doesn't do the ftruncate() in this case. But it still tries to back out. This results in write() returning -1/EIO. This is wrong if something has been successfully written. On second thoughts is it is the best possible behaviour. Everything in the region of the file covered by the write() may have been clobbered, either by writing the requested bytes, or by a hardware or software error writing garbage, or by the intentional zeroing for security. The only way to tell the application about this is to say that the whole write failed. The application should assume that the entire region has been clobbered, and take steps to check and limit the extent of the damage, perhaps by trying to rewrite it all in smaller pieces. There seem to be more bugs in [f]truncate(): - POSIX requires SIGXFSZ for attempts to exceed the file size rlimit in truncate() too, but FreeBSD doesn't even check the rlimit for truncate(). Checking the rlimit in vfs makes all this easier to fix. I think write() can be fixed in a couple of lines in vfs. All file systems call back to vfs to check, though I don't know of any requirement for other errors to have precedence, so vfs could check up front. zfs's write vnop actually calls back to vfs before doing anything else, so this error already has precedence over all fs-specific errors for zfs. All other file systems' write vnop do the check a fair way into the vnop in much the same place as ffs. No file systems check the limit for truncate(). The limit checking is commented out in xfs's write vnop. Bruce
Responsible Changed From-To: freebsd-bugs->freebsd-standards Canonicalize assignment.
----- Forwarded message from Bruce Evans <brde@optusnet.com.au> ----- Date: Mon, 21 Apr 2014 16:24:52 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: linimon@freebsd.org Subject: Re: standards/164793: [libc] write(2) system call violates POSIX standard On Sun, 20 Apr 2014 linimon@freebsd.org wrote: > Old Synopsis: 'write' system call violates POSIX standard > New Synopsis: [libc] write(2) system call violates POSIX standard Should be '[kern]'. I see I wrote too much in the followup. The PR is mostly about RLIMIT_FSIZE not working, and this also affects ftruncate() and truncate(), and is is probably fs-dependent with zfs and fusefs possibly not having it, so write(2) is not very descriptive either. > Responsible-Changed-From-To: freebsd-bugs->freebsd-standards This is correct. Bruce ----- End forwarded message -----
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
Still a bug in 14.0-CURRENT. No file system checks RLIMIT_FSIZE during truncate.
https://reviews.freebsd.org/D36625
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a9c439ba104d83a2666d114dae9f26b2efb22d17 commit a9c439ba104d83a2666d114dae9f26b2efb22d17 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:51:33 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-09-24 16:42:01 +0000 msdosfs: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE PR: 164793 Reviewed by: asomers, jah, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D36625 sys/fs/msdosfs/msdosfs_vnops.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=87525ef94007c792c6745db7938251a663ca5706 commit 87525ef94007c792c6745db7938251a663ca5706 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:48:40 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-09-24 16:41:57 +0000 FFS: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE PR: 164793 Reviewed by: asomers, jah, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D36625 sys/ufs/ffs/ffs_vnops.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1b4b75171ee3f2213b7671878a910fd5ddb3306e commit 1b4b75171ee3f2213b7671878a910fd5ddb3306e Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:46:19 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-09-24 16:41:33 +0000 Add vn_rlimit_fsizex() and vn_rlimit_fsizex_res() The vn_rlimit_fsizex() function: - checks that the write does not exceed RLIMIT_FSIZE limit and fs maximum supported file size - truncates write length if it exceeds the RLIMIT_FSIZE or max file size, but there are some bytes to write - sends SIGXFSZ if RLIMIT_FSIZE would be exceed otherwise POSIX mandates the truncated write in case when some bytes can be written but whole write request fails the RLIMIT_FSIZE check. The function is supposed to be used from VOP_WRITE()s. Due to pecularity in the VFS generic write syscall layer, uio_resid must correctly reflect the written amount (noted by markj). Provide the dual vn_rlimit_fsizex_res() function to correct uio_resid after the clamp done in vn_rlimit_fsizex() on VOP_WRITE() return. PR: 164793 Reviewed by: asomers, jah, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D36625 sys/kern/vfs_vnops.c | 92 +++++++++++++++++++++++++++++++++++++++++++++------- sys/sys/vnode.h | 3 ++ 2 files changed, 83 insertions(+), 12 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=701b73858e3afa15d8ca2ea4aa480173ccc5960e commit 701b73858e3afa15d8ca2ea4aa480173ccc5960e Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:51:03 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-09-24 16:41:26 +0000 msdosfs: disallow truncation to set file size past RLIMIT_FSIZE PR: 164793 Reviewed by: asomers, jah, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D36625 sys/fs/msdosfs/msdosfs_vnops.c | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b5b16659c5aceb9caa0a9b76c7746e1d12a505ce commit b5b16659c5aceb9caa0a9b76c7746e1d12a505ce Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 13:28:11 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-09-24 16:41:30 +0000 tmpfs: disallow truncation to set file size past RLIMIT_FSIZE PR: 164793 Reviewed by: asomers, jah, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D36625 sys/fs/tmpfs/tmpfs_subr.c | 4 ++++ 1 file changed, 4 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=70385088cafaab3365c5243f22b8fc9c712c1fde commit 70385088cafaab3365c5243f22b8fc9c712c1fde Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:49:57 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-09-24 16:41:22 +0000 UFS: disallow truncation to set file size past RLIMIT_FSIZE This is mandated by POSIX. PR: 164793 Reviewed by: asomers, jah, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D36625 sys/ufs/ufs/ufs_vnops.c | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8bdb2695d69710b7f2e7cc20820aab8b3f4668a6 commit 8bdb2695d69710b7f2e7cc20820aab8b3f4668a6 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 13:27:28 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-09-24 16:42:05 +0000 tmpfs: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE PR: 164793 Reviewed by: asomers, jah, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D36625 sys/fs/tmpfs/tmpfs_vnops.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0a192b3abab19deac70f762cd1ec45ba09ec47ca commit 0a192b3abab19deac70f762cd1ec45ba09ec47ca Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2022-09-25 17:56:11 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2022-09-25 21:02:23 +0000 fusefs: respect RLIMIT_FSIZE during truncate PR: 164793 MFC after: 2 weeks Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D36703 sys/fs/fuse/fuse_vnops.c | 3 +++ tests/sys/fs/fusefs/setattr.cc | 44 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 46 insertions(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=be280f60dd8e8ef765a76966aac9c6ca7d6264d0 commit be280f60dd8e8ef765a76966aac9c6ca7d6264d0 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2022-09-25 18:59:33 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2022-09-25 21:02:59 +0000 fusefs: truncate write if it would exceed RLIMIT_FSIZE PR: 164793 MFC after: 2 weeks Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D36703 sys/fs/fuse/fuse_io.c | 16 ++++++--- tests/sys/fs/fusefs/write.cc | 78 ++++++++++++++++++++++++++++++++++++++------ 2 files changed, 80 insertions(+), 14 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2bd3dbe3dd60aeb84ebc52f23f0f4205d3eb082d commit 2bd3dbe3dd60aeb84ebc52f23f0f4205d3eb082d Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 13:27:28 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-10-08 00:29:36 +0000 tmpfs: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE PR: 164793 (cherry picked from commit 8bdb2695d69710b7f2e7cc20820aab8b3f4668a6) sys/fs/tmpfs/tmpfs_vnops.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=55b41282d698bed4b3bb75b74265992c2cf5f42b commit 55b41282d698bed4b3bb75b74265992c2cf5f42b Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:48:40 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-10-08 00:29:36 +0000 FFS: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE PR: 164793 (cherry picked from commit 87525ef94007c792c6745db7938251a663ca5706) sys/ufs/ffs/ffs_vnops.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=337b0852e942205246f16c30a923900edbb16a8c commit 337b0852e942205246f16c30a923900edbb16a8c Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:51:33 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-10-08 00:29:36 +0000 msdosfs: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE PR: 164793 (cherry picked from commit a9c439ba104d83a2666d114dae9f26b2efb22d17) sys/fs/msdosfs/msdosfs_vnops.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f0ebdb4254e81feb726a58a38a399a95f307f656 commit f0ebdb4254e81feb726a58a38a399a95f307f656 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:46:19 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-10-08 00:29:36 +0000 Add vn_rlimit_fsizex() and vn_rlimit_fsizex_res() PR: 164793 (cherry picked from commit 1b4b75171ee3f2213b7671878a910fd5ddb3306e) sys/kern/vfs_vnops.c | 92 +++++++++++++++++++++++++++++++++++++++++++++------- sys/sys/vnode.h | 3 ++ 2 files changed, 83 insertions(+), 12 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=064d5d4dee053f70ff82f9a1f98ed42e38f36b47 commit 064d5d4dee053f70ff82f9a1f98ed42e38f36b47 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 13:28:11 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-10-08 00:29:35 +0000 tmpfs: disallow truncation to set file size past RLIMIT_FSIZE PR: 164793 (cherry picked from commit b5b16659c5aceb9caa0a9b76c7746e1d12a505ce) sys/fs/tmpfs/tmpfs_subr.c | 4 ++++ 1 file changed, 4 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3936744da50c0f10466780305208f61542131898 commit 3936744da50c0f10466780305208f61542131898 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:49:57 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-10-08 00:29:35 +0000 UFS: disallow truncation to set file size past RLIMIT_FSIZE PR: 164793 (cherry picked from commit 70385088cafaab3365c5243f22b8fc9c712c1fde) sys/ufs/ufs/ufs_vnops.c | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=27ec1f0833a153c4052c74e0863c556057735b26 commit 27ec1f0833a153c4052c74e0863c556057735b26 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2022-09-18 11:51:03 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2022-10-08 00:29:35 +0000 msdosfs: disallow truncation to set file size past RLIMIT_FSIZE PR: 164793 (cherry picked from commit 701b73858e3afa15d8ca2ea4aa480173ccc5960e) sys/fs/msdosfs/msdosfs_vnops.c | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0f0a0bdff052e4a61b20f6a0fc252e381c57c3ab commit 0f0a0bdff052e4a61b20f6a0fc252e381c57c3ab Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2022-09-25 18:59:33 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2022-10-12 04:49:34 +0000 fusefs: truncate write if it would exceed RLIMIT_FSIZE PR: 164793 Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D36703 (cherry picked from commit be280f60dd8e8ef765a76966aac9c6ca7d6264d0) sys/fs/fuse/fuse_io.c | 16 ++++++--- tests/sys/fs/fusefs/write.cc | 78 ++++++++++++++++++++++++++++++++++++++------ 2 files changed, 80 insertions(+), 14 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b9f82f035af41476e5b73ab72292a84a346f0941 commit b9f82f035af41476e5b73ab72292a84a346f0941 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2022-09-25 17:56:11 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2022-10-12 04:49:26 +0000 fusefs: respect RLIMIT_FSIZE during truncate PR: 164793 Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D36703 (cherry picked from commit 0a192b3abab19deac70f762cd1ec45ba09ec47ca) sys/fs/fuse/fuse_vnops.c | 3 +++ tests/sys/fs/fusefs/setattr.cc | 44 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 46 insertions(+), 1 deletion(-)