I think @markj may be interested too.

Here's a brain dump of what I had been thinking about a possible iterator, which is not very refined.

So this supports a split insert/lookup, correct? Like the idea is that it lets us do something with the previous entry before we complete the insert?

In D45486#1038012, @alc wrote:

In principle, this is fine, but in practice. we mostly call vm_page_insert_after(). So, the impact will be limited. That said, I'm still excited by where I think this is headed.

markj feedback: predict success

Mark vm_page_insert_lookup as __always_inline, and reword the comment.

markj feedback: comment typo

markj feedback: reword comment, remove unneeded NULL check

In D45396#1037485, @markj wrote:

I guess vm_page_insert() could be improved similarly, but that's more work.

dougm feedback: kassert readability

dougm feedback: simplify error paths

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.