kib style feedback

kib feedback on style and __result_use_check

kib feedback on KASSERT style, and fix a comment typo

Filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279354

What about arc_available_memory() in sys/contrib/openzfs/module/os/freebsd/zfs/arc_os.c? Isn't that still broken?

In D45360#1034889, @kib wrote:

LK_NOWAIT is the common pattern for this situation. Besides buffers, another immediate example is the vm_map lock in vmspace_fork() (look for the new_map locking and comment).

alc feedback: const and style fixups

markj feedback: elaborate on comment and provide vm_batchqueue_empty()

Implement markj's suggestion

In D45287#1033196, @jhibbits wrote:

The only time this makes a difference is if the sizes of bus_addr_t and bus_size_t are different, and I don't have any test hardware where that's the case and I can test TPM. (Only hardware I have where that's the case is ppc Book-E, but that doesn't have a TPM).

• getblk: fail faster with GB_LOCK_NOWAIT
• GB_LOCK_NOWAIT markj feedback

In D45245#1032681, @markj wrote:

My only comment is that, reading the code, it's not immediately obvious why we give up right away when failing to acquire the buf lock, but not when we successfully acquire the buf lock and discover that the buffer identity has changed.

@glebius I ran into this while running the kern tests. This new test is failing reliably for me, and it looks like in CI too, e.g. this run on April 9:
https://ci.freebsd.org/job/FreeBSD-main-amd64-test/25066/testReport/sys.kern/unix_seqpacket_test/random_eor_and_waitall/

In D45245#1032333, @kib wrote:

I think that this is technically correct but unfair. Intent was that failed unlocked buffer lookup should not change the behavior, in particular, allowing the normal lookup quirks to proceed.

LGTM. I don't get why we don't send PC and the watch stop reason in the '?' case but it probably doesn't matter and it looks like a faithful refactor.

I don't have an objection to changing the LOG_WARNING to LOG_ERR, but I'm confused about what this actually changes. I looked at man 3 syslog and vsyslog1() to see if we printed to stderr by default for LOG_ERR but I'm not seeing that. So, what does this actually do?

A NULL check seems like a clear improvement over a crash.

In D28762#697585, @arichardson wrote:

Seems like this is needed to build stable/13 with GCC. Are you going to MFC this? If not I can cherry-pick it for you.

Will work on a providing a better semaphore first.

In D29542#662307, @mjg wrote:

I disagree with the patch.

The current mechanism is crap and should probably be retired, anyone interested in ramping up kernel memory use has plenty of other ways to do it.

LGTM, and I checked $work's tree for other references.

Change looks fine once the i386 hack is restored.

This can be done without introducing another object pointer (nobj) by resetting lobj and following the pattern elsewhere, but I found the approach with nobj to be more readable.