Maybe to make it clearer we can change the struct to use a union of next_seqno and initial_seqno which won't change the ABI but will let us document it in the header and be more clear about the intent?

I actually have a much larger diff I'm working on to consistently use unsigned types for lengths in this header as well as fixing some potential integer overflow issues. I'll try to upload that later this week. I think I also fixed an overflow check in this patch as well as part of that.

Drop memset

Update after removing BUS_IVAR_GICV3

Rename BUS_IVAR_GIC3 to BUS_IVAR_GICV3

Hmm, so does (vm_offset_t)&end still work after this change or should it instead drop the &?

Ah, so you could use (char *)foo - end in place of the casts? But not &end?

I think we just need some sort of IVAR we can test for and this is just as easy as any other. Can you test this to make sure it works? I have only compile tested it as my only FreeBSD box with TB has the older chipsets that don't work.

In D54148#1237250, @igoro wrote:

In D54148#1237012, @jhb wrote:

Igor, are you able to test this again on your armv7 setup btw?

My testing passed. Now it's clear that my attempt to avoid extra copying on each reallocation was based on an assumption that isn't always true. It's a good plan to get back to always copying on each reallocation, as it was before, and think about an actual "buffer extension" mechanism that could be triggered when applicable.

I've had no luck getting responses from any drm-kmod folks despite pinging on reviews. I think I will just go ahead and push this to main now and reply to the commit saying it breaks drm-kmod and letting the drm-kmod folks sort it out.

In D54148#1236974, @kp wrote:

What's this based on? It doesn't seem to want to apply to FreeBSD main (f9500e75791cf793904c80ca4a52433afd585a23).

I manually applied it to my cheri tree, and that does indeed work.

Hopefully rman routines are not used in any critical paths (attach/detach handlers should be a relatively rare path compared to, say, an interrupt handler)

After reverting my earlier fix (which I don't intend to MFC and by which I was distracted by the "optimization" of reusing the existing buffer), this fixes pfctl for me on CHERI. In effect, it makes Igor's original commit just add the missing 'nw->size = new_size'. I think that probably explains both of the issues Igor noted in the original commit log. The buffer overflows were caused by nw->offset exceeding nw->size and eventually the realloc'd buffer was simply too small as it was only 'nw->size + <size of current object needed>' which could easily be smaller than 'nw->offset' once you've appended a few things larger than the initial buffer size.

Hmmm, I wonder if 0 is the right thing vs something like 0xdeadc0de. We have a few explicit IVAR handlers that intentionally return a default value (e.g. acpi_get_handle()) and those do tend to be zero (and in those cases we don't KASSERT). I have a patch in a branch to add a new one like that for ThunderBolt PCI bridges even. 0 is probably fine as a default, but @imp might also have an opinion.

In D54051#1234938, @olce wrote:

There is an occurrence of "swapper" in sys/vm/vnode_pager.c that seems to also point to the swapper process.

Use ruxreset