It is fine, except one detail that I do not like. You do the late pass after the APs were released.

Provide the amd64 example, in binary form.

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#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?

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.

In D23913#563590, @mjg wrote:

In D23913#563051, @kib wrote:

In D23913#563019, @mjg wrote:

I don't see it. Relying on dooming would require moving the VIRF_DOOMED flag into hold count to maintain atomicity vs vhold_smr. It would be the same patch + more work.

I asked pho to test the updated version.

I mean get the transient reference, check for DOOMED, drop the reference if DOOMED and return failure from cached lookup.

I see two problems there:

• setting DOOMED and checking hold count for free should be ordered (arguably it already is)
• transient reference might either break some asserts or cause missed free.

I think that only missed free is serious enough to be counter-argument, but it might be fixable with less work than making the hold count flagged counter.

Well to expand on it the race between freeing the vnode and vhold_smr is the crux here. I tried to not have the flag in the count, but as it is there is no way to know when the vnode is no longer reachable. With the change as proposed we maintain the invariant that vnode handed over to uma_zfree will never get any new references (even transient). Consequently I think this is the most debuggable approach in the long run.

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.

In D25493#563935, @jhb wrote:

I believe this is correct. I think you only put things in Symbol.map if you want them public for when you link new binaries. We use __sym_compat without any corresponding Symbol.map entries for other compat shims in libc (e.g. fts* symbols in lib/libc/gen/Symbol.map are only the latest FBSD1.5 version and don't include the legacy versions for FBSD1.0 and FBSD1.1.)

In D25511#563838, @andrew wrote:

Do we need a similar change in arm64 and i386?

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.

Fix pv list locking in pmap_remove_pde(), restore assert in pmap_delayed_invl_page().

In D25483#563292, @markj wrote:

As I understand, for correctness, the return-from-exception code must restore the default ucr3 mask (PMAP_UCR3_NOMASK). If it fails to do so, a subsequent exception+return to usermode will use a stale mask and thus will fail to flush upt TLB entries. Is that right?

Handle the latest batch of reviewer' notes.

In D24217#563206, @markj wrote:

The introduction of PVLL and conversion from rw_lock/unlock to pv_list_lock/unlock could have been done separately, for instance.

My intent was to try to split commits. Maintaining the split with git-svn workflow is too much work.

Add asserts about interrupt enable state.
Collape pmap_activate_sw_pcid_pti1() into the caller.

In D25483#563256, @markj wrote:

Just to make sure that I understand: the idea is to reduce the amount of work done in invalidation handlers, by deferring the flush of upt TLB entries until the interrupted thread is about to switch back to user mode?

In D23913#563019, @mjg wrote:

I don't see it. Relying on dooming would require moving the VIRF_DOOMED flag into hold count to maintain atomicity vs vhold_smr. It would be the same patch + more work.

I asked pho to test the updated version.

Handle wakeup.
Update description of ptepindex.

I think this is fine on principle.

In D25451#562953, @cem wrote:

We could provide dummy implementations of these symbols, rather than enabling SSLv3 code in 2020 in our unreleased development version of FreeBSD.

In D25451#562076, @kib wrote:

In D25451#562063, @cem wrote:

For example, when we moved from openssl 1.0 to 1.1 in base, that broke ABI for anything linking against base openssl.

We did not, because the dso version was bumped.

That is an interesting definition of ABI stability. I do not think it is a useful one. When we bumped SONAME, we also removed the old DSO version, breaking any program that linked to it. Removing an entire DSO SONAME is a bigger ABI break than a handful of SSLv3 symbols.

The solution here is to not break most things most of the time. Removing SSL3 is a good use of the limited exception to the general rule. Binaries that want to depend on known-broken parts of OpenSSL should link a specific version from ports. SSL3 (1996) has had security smell since as early as 2005 (early SHA1 weaknesses) and was completely broken in 2014 with POODLE; it was deprecated in 2015.

Point of binary compatibility is that you have the binary continuing working. If you force somebody to relink the binary it is exactly the reverse of ABI stability.
And if somebody cannot relink, he is left with a broken system that cannot be fixed.

Bumping SONAME is worse than removing SSLv3 symbols in all of these respects.

In which way ?

comma

Where is VHOLD_NO_SMR set ?

Alc suggestions.

Separately mention the root page.

Change herald sentence as suggested by Mark. Add articles.

In D25304#562372, @jhb wrote:

It also affects what OSABI GDB assigns if you do 'file /path/to/dso' or 'add-symbol-file /path/to/dso'. Mostly this would matter in the context of GDB used on a non-FreeBSD host (on FreeBSD hosts the fallback default OSABI is FreeBSD, so when you fail to recognize a shared library, it ends up still working due to the accident).

Removing the EI_OSABI check on aarch64 and riscv64 means ldd would try to dlopen() Linux shared libraries on those platforms instead of erroring out.

In D25451#562063, @cem wrote:

Sure, and sometimes that's fine.

For example, when we moved from openssl 1.0 to 1.1 in base, that broke ABI for anything linking against base openssl.

We did not, because the dso version was bumped.

In D25451#562007, @cem wrote:

Because you cannot get stable branches ABI-stable if head is not.

I don't understand this remark, can you elaborate? Thanks.

In D25451#561969, @cem wrote:

Er, why? CURRENT is not ABI stable and SSLv3 is very broken. Applications that want to use a broken cipher can get that from ports.

Handle the first round of comments.

Agreed, sorry for the noise.

I am not sure what you see in dtrace, but I see a bug in ffs_write() regardless of IO_DATASYNC. D25404