Document EINTEGRITY errors for many system calls.

[jhb]

Summary

EINTEGRITY was previously documented as a UFS-specific error for
mount(2). This documents EINTEGRITY as a filesystem-independent error
that may be reported by the backing store of a filesystem.

While here, document EIO as a filesystem-independent error for both
mount(2) and posix_fadvise(2). EIO was previously only documented
for UFS for mount(2).

Suggested by: mckusick

[mckusick]

While read(2) and write(2) are the most likely system calls to return EINTEGRITY, really any system call that accesses a filesystem can potentially return EINTEGRITY. Using the metric that if it can return EIO, then it can now return EINTEGRITY leads to this list of system calls needing EINTEGRITY added: access.2, acct.2, bind.2, chdir.2, chflags.2, chmod.2, chown.2, chroot.2, copy_file_range.2, execve.2, fhlink.2, fhreadlink.2, fsync.2, getdirentries.2, getfh.2, getfsstat.2, intro.2, ktrace.2, link.2, lio_listio.2, mkdir.2, mkfifo.2, mknod.2, mount.2, msync.2, open.2, pathconf.2, posix_fallocate.2, quotactl.2, readlink.2, rename.2, rmdir.2, sendfile.2, stat.2, statfs.2, swapon.2, symlink.2, truncate.2, undelete.2, unlink.2, utimensat.2, and utimes.2.

[jhb]

• Add EINTEGRITY to most of the manpages which reference EIO.

[jhb]

• Add EINTEGRITY to most manpages that document EIO.

[jhb]

Ok, I've tried to add EINTEGRITY to all the places I could find that I think are relevant using EIO as a guide. Note that msync(2) coalesces all filesystem errors into EIO, so I did not add it to that manpage. Similarly, lio_listio(2) returns EIO explicitly so I did not add it there. I haven't done any Dd bumps but will do that prior to commit once it is approved. Also, please see the comment on symlink(2) and it's duplicate EIO errors as I'd be happy to fix that as part of this unless you'd like to fix it directly instead.

lib/libc/sys/rename.2

241 ↗

(On Diff #69874)

So this manpage is a bit unique. It has duplicate entries for EIO. Kirk added the first EIO entry in May of 1985 (https://svnweb.freebsd.org/csrg?view=revision&revision=21004) and the second from a submitted patch a few months later in August (https://svnweb.freebsd.org/csrg?view=revision&revision=24440). I'll let Kirk decide which EIO description to keep and will drop the duplicate as part of this change as well. :)

[mckusick]

This looks complete. I had missed the VOP_* manual pages, good catch.
I am happy to have you clean up the duplicate EIOs.
Thanks for doing this.

lib/libc/sys/mkfifo.2

136 ↗

(On Diff #69874)

It seems like this second generic EIO can be eliminated as the one above it does a better job of describing why it can occur.

lib/libc/sys/rename.2

241 ↗

(On Diff #69874)

I do not see another EIO in rename. Did you mean to put this comment in symlink (where there are duplicate EIO's)?
The two revisions you cite above both add the same text for EIO, but I see only one instance of EIO in the present day man page.

lib/libc/sys/symlink.2

124 ↗

(On Diff #69874)

This is the EIO to keep as it has a more complete description.

153 ↗

(On Diff #69874)

This is the EIO to delete as the one above has a more complete description.

[jhb]

I think it's best to do the EIO changes as a followup.

lib/libc/sys/mkfifo.2

136 ↗

(On Diff #69874)

I can do that. For this manpage I had assumed it was somewhat intentional (since they were adjacent) and that the second error was a bit more generic to handle non-UFS filesystems. However, it's best that we are consistent.

lib/libc/sys/rename.2

241 ↗

(On Diff #69874)

Yes, this was for symlink(2) sorry.