Allow the implementation to direct busy state changes

In D30152#678936, @markj wrote:

Do you plan to revise this change after changing the VFS_QUOTACTL interface? I'm just not sure whether to wait until that's done before re-reading this.

Use correct variable when passing through VFS_QUOTACTL

Follow the unbusy requirements for vfs_quotactl()

Style

Use atomic_load_ptr to enforce single load of vp->v_mount

Apply vfs_busy, minor refactoring

In D30152#677009, @kib wrote:

In D30152#677007, @jah wrote:

In D30152#676937, @jah wrote:

A simpler approach would be to directly store the underlying mount objects in struct unionfs_mount, vfs_ref() them on mount and vfs_rel() them on unmount.
But that would have the effect of blocking forcible unmount of the underlying filesystems in vfs_mount_destroy(). Meanwhile, the underlying FS' vnodes would still be flushed before this happens so the underlying filesystems would be no more usable than they are with this approach.

In D30152#676980, @kib wrote:

Taking a reference on the mount point does not prevent unmount. For instance, calling VFS_QUOTACTL() requires busying mp, which, if successful, prevents unmount until unbusy. In fact, busying fs is currently enforced by VFS_QUOTACTL protocol since UFS (the only actual quotactl provider) in some cases unbusies and then busies the mp.

It certainly doesn't prevent the unmount operations (vflush, etc) from happening, but doesn't it prevent the unmount system call from returning? That's what I observed in testing, and is corroborated by reading vfs_mount_destroy().

Why 'preventing syscall from returning' matters? What matters is that unmount destroys the private mount data pointed to by mnt_data. This data is usually vital for VFS_XXX() methods, and destroying/freeing it while these methods operate causes undefined behavior, a crash in the best case.

In D30152#676937, @jah wrote:

A simpler approach would be to directly store the underlying mount objects in struct unionfs_mount, vfs_ref() them on mount and vfs_rel() them on unmount.
But that would have the effect of blocking forcible unmount of the underlying filesystems in vfs_mount_destroy(). Meanwhile, the underlying FS' vnodes would still be flushed before this happens so the underlying filesystems would be no more usable than they are with this approach.

A simpler approach would be to directly store the underlying mount objects in struct unionfs_mount, vfs_ref() them on mount and vfs_rel() them on unmount.
But that would have the effect of blocking forcible unmount of the underlying filesystems in vfs_mount_destroy(). Meanwhile, the underlying FS' vnodes would still be flushed before this happens so the underlying filesystems would be no more usable than they are with this approach.

Adjust wording in comment, rearrange return value assertion

Fix la57 table accounting

--remove unnecessary include
--add la57 bootstrap accounting
--further cleanup to improve code reuse

Revert accidentally-committed PCID counter removal, incorporate resident_count

In D28923#650048, @kib wrote:

I probably should have been more explicit, I proposed to drop the pt_page_count at all. But I hope that you will follow up with pmap_pt_page_alloc() patch so this does not matter much.

• Revert "Remove PCID save count, factor out PT page allocation/freeing"
• Fix NULL check in pmap_large_map_getptp_unlocked()

• Remove PCID save count, factor out PT page allocation/freeing

In D28592#640118, @mjg wrote:

I have no comments about usefulness of adding these counters. I have to note the patch negatively affects scalability as it adds loads from the page form something which gets modified by other threads. If adding these stats, it would have to happen inside of vm_page_busy_sleep.

Whitespace

Seemed like a cute driver and a fun thing to do with some spare time while I was traveling.
I've verified that spkrtest(8) cycles through the notes without error, but since I'm away from the one machine I have with an actual speaker, I haven't been able to test by ear.

Factor locking/unlocking into kenv_acquire() and kenv_release(), and use them for some light cleanup

Return kenv_lock to a mutex

In D26010#576845, @mjg wrote:

The statement was that rmlocks distribute the lock per-CPU which means increased memory use. There are cases where this is perfectly warranted of course, I just doubt this one qualifies.

kenv should almost never be used past boot and even then I highly doubt the lock is contended enough to warrant any non-trivial changes. There may be offenders which keep re-reading the same value when they could do it once, but I don't think they are worth tracking down either. I do suspect there are nice wins to get like avoiding memory alloc (which also happen to fix bugs), but past that I would suggest not messing with the area.

In my opinion justifying this particular conversion would require a real world workload running into the problem which happens to not abuse the interface (like aforementioned re-reads of the same stuff), but I doubt there is something legitimate like this out there. However, I'm not going to stand in the way.

In D26010#576843, @mjg wrote:

Is kenv frequently used to begin with? rm lock would add memory use per-cpu, so arguably it would be a pessimization. I also suspect we may be able to get away without any locks to begin with with some trickery.

Either way, I think the change to strtok in place is a good idea and an equivalent should be done for other routines if applicable.

That said, can you please open a separate review for the locking change and only keep the actual bugfix here?

ping