Improve POSIX compliance for RLIMIT_FSIZE

[kib]

Summary

When there are some bytes to write in case write overflows the limit, truncate the write instead of sending SIGXFSZ outright.
Send SIGXFSZ when truncating.

Only UFS, msdosfs, tmpfs are handled.

Per-commit view https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=shortlog;h=refs/heads/ufs

PR: 164793

[asomers]

Thanks for fixing this. As for what the correct behavior should be when the file doesn't yet exceed the limit but a write would cross that threshold, I'm agnostic. I think the old behavior of aborting the write entirely was fine. But the new behavior is fine too. I can fix truncate with fusefs after you merge this change.

[kib]

In D36625#831484, @asomers wrote:

As for what the correct behavior should be when the file doesn't yet exceed the limit but a write would cross that threshold, I'm agnostic. I think the old behavior of aborting the write entirely was fine. But the new behavior is fine too.

If the request would cause the file size to exceed the soft file size limit for the process and there
is no room for any bytes to be written, the request shall fail and the implementation shall
generate the SIGXFSZ signal for the thread.

From the decription of write() in IEEE Std 1003.1™-2017

[markj]

sys/fs/tmpfs/tmpfs_vnops.c

660 ↗

(On Diff #110714)

663 ↗

(On Diff #110714)

I think VFS_TO_TMPFS(vp->v_mount)->tm_maxfilesize deserves a local variable.

sys/ufs/ffs/ffs_vnops.c

895 ↗

(On Diff #110714)

In dofilewrite(), we compare resid before and after the operation to determine whether to return to userspace, and to determine the return value for write(). Won't this clamping break it?

[kib]

Fix the issue with uio_resid:

• move both limit check and max file size check into new helper vn_rlimit_fsizex(), and clamps uio_resid
• the helper returns original uio_resid, which must be passed to vn_rlimit_fsizex_res() on return
• _res() adjusts uio_resid back to the original value minus processed bytes

vn_rlimit_fsize() is kept around for unconverted filesystems, but is implemented by using compat mode in vn_rlimit_fsizex()

[markj]

sys/kern/vfs_vnops.c

2393 ↗

(On Diff #110831)

A comment or some other kind of documentation is needed to know when to use this variant.

2434 ↗

(On Diff #110831)

or maybe "... can handle writes truncated to the file size limit".

2463 ↗

(On Diff #110831)

Why not simply drop the const qualifier from the function?

[kib]

sys/kern/vfs_vnops.c

2463 ↗

(On Diff #110831)

Because I think it would be wrong, the function does not modify *uio. DECONST there is an implementation detail.

Also, after all filesystems are converted, vn_rlimit_fsize() should be removed.

[kib]

Update comments

[kib]

After Peter testing; fixed bugs.

Always update *orig_resid, since vn_rlimit_fsizex_res() is called unconditionally.
Interpret maxfsz == 0 as no file size limit.
Do not exclude file size limit check for td == NULL case (kernel write).
Improve comments.

[markj]

sys/kern/vfs_vnops.c

2413 ↗

(On Diff #110917)

Is there some specific reason putpages does not set uio_td? Other kernel writers (e.g., md thread) do set it.

[kib]

sys/kern/vfs_vnops.c

2413 ↗

(On Diff #110917)

I suspect it comes down to the question of the ownership of the writes. vnode_pager is executed in context which is, generally, different from the thread that dirtied the pages. In particular, this was a bug I have in the intermediate version of vn_rlimit_fsizex().

Current nfs client forcibly set uio_td to curthread in nfs_putpages(), I did not checked what did the old client. Perhaps other network filesystems could be affected too.

Note that e.g. md(4) worker thread is the owner of writes, so setting uio_td to md thread is correct.