No discussion, just my own previous inspection when I was doing sealing stuff. Looking again, I see that you're correct -- the only thing that would seemingly break is libprocstat's procstat_get_shm_info_kvm.

In D25502#564824, @kevans wrote:

My recollection was that we can't really change struct shmfd like that on stable without KBI break, and we should probably fix it at least on stable/12; leading to "ok, just validate it for the MFC then we can drop the check and expand shm_size after."

In D25502#564823, @kib wrote:

In D25502#564805, @kevans wrote:

In D25502#564145, @kib wrote:

In D25502#563934, @kevans wrote:

For this current diff, it occurs to me that this specific instance should be checking for overflow of SIZE_MAX rather than OFF_MAX since shm_size is a size_t. I'll make that tweak pre-commit.

Uhh. So the check in shm_dotruncate_locked() is boosted, and also we could have mis-synchronization between shm_object size and shm_size.

I'll (separately) add a check for length > SIZE_MAX in shm_dotruncate_locked and kick back an EFBIG there; is there another source of mis-synchronization for shm_object size and shm_size, or are you generally referring to the truncation of shm_size that could happen when assigning the off_t length to 32-bit quantity?

I am not sure why check for SIZE_MAX and not change shm_size type to either off_t or better vm_ooffset_t.

In D25502#564805, @kevans wrote:

In D25502#564145, @kib wrote:

In D25502#563934, @kevans wrote:

For this current diff, it occurs to me that this specific instance should be checking for overflow of SIZE_MAX rather than OFF_MAX since shm_size is a size_t. I'll make that tweak pre-commit.

Uhh. So the check in shm_dotruncate_locked() is boosted, and also we could have mis-synchronization between shm_object size and shm_size.

I'll (separately) add a check for length > SIZE_MAX in shm_dotruncate_locked and kick back an EFBIG there; is there another source of mis-synchronization for shm_object size and shm_size, or are you generally referring to the truncation of shm_size that could happen when assigning the off_t length to 32-bit quantity?

Sorry, newbie learning way around arc. Seems it grabbed an unintended commit.

Slightly less code motion; tested using qemu "-append -s" on FreeBSD machine I'd forgotten about.

In D25502#564145, @kib wrote:

In D25502#563934, @kevans wrote:

In D25502#563799, @kib wrote:

I realized that we do not check for the overflow in vn_io_fault() either.
I am fine with this commit as-is, and you could fix vn_io_fault() (if needed) later.
For instance, despite no check on filedesc/VFS layer, ffs_write() eventually does

	if ((uoff_t)uio->uio_offset + uio->uio_resid > fs->fs_maxfilesize)
		return (EFBIG);

which probably is good enough to avoid corruption for FFS.
But rangelocks are probably not immune.

Sure- I'll check out vn_io_fault later. I'm somewhat unsure about what to do there; it seems like in some cases (e.g. shmfd) it could make sense to allow the overflow because the file won't grow like most traditional filesystems so we'll just truncate the write to the pre-allocated size of the file. It would be simpler to not care about shmfd being an odd duck.

vn_io_fault() is not used for shmfd.

My general concern there is that overflow for end causes rangelocks to misbehave. This is besides a possibility that some filesystems might be not prepared to this as well.

• assorted cleanups
• fix a ref leak on fallback error

Add untested amd64 support

bhyve: Handle guest' LA57 paging mode.
This is in fact independent of the rest of the patch, since guest can set the bit in %cr4 at will.

Refresh patch after rebase. Fix conflicts in vm_map.c.

Thank you for raising this diff! Was going to do the same, but you managed to do it faster :-)
LGTM, please see the naming comment :-)

In D25531#564692, @jrtc27 wrote:

Also, are we guaranteed to have the *post_ithread* hook run on the same hart? If not we'll complete for the wrong hart (though in practice all implementations I know of only track claims on a global basis so don't care which hart's claim/complete register you write to).

Well, fixed the panics (which happened on BOOT on the first patch).

This patch currently panics and needs revision

Thank you!

Revised in light of jrtc27's comments. Unfortunately, I lack a FreeBSD box to build and test this on (sorry, CheriBSD builds fine and I didn't think about our being lagged relative to upstream); perhaps someone who does would be so kind as to let me know if I've broken something?