Please be sure to include a Fixes: tag in the commit log message.

I think the patch is ok with my comments addressed.

In D57381#1330788, @zishun.yi.dev_gmail.com wrote:

In D57381#1330138, @markj wrote:

@zishun.yi.dev_gmail.com could you please rebase this patch so that it applies to the latest main? I don't really like the diff to riscv/include/atomic.h, and would like to explore different approaches. (Really I'd like to get rid of all of these interceptors entirely, but the best way to do that is probably to reimplement atomic.h using C11 atomics...)

Yeah, I agree the current code is ugly, and your approach sounds great.

For now I've moved most of the ugly code into a separate revision(D58037) so it doesn't block the riscv work. That part could well be refactored entirely in the future , so keeping it separate from the KASAN changes seems cleaner.

Simplify

I think this is ok. The result is not quite the same as what I proposed originally: I believe, with your patches, that if a process creates a child with pdfork(), then it cannot use pdwait() to reap the child, it still must use waitpid(). It would be nicer to make pdwait() reap the child in this case, IMO.

This was addressed in commit d05d1f2560823 by @pouria .

This isn't needed anymore.

I've been using git-mfc instead, which I think has a superset of the functionality in mfc-candidates.

I've been using git-mfc instead, which I think has a superset of the functionality in mfc-candidates.

This is also bugzilla PR 296835: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296835, please include that in the commit log message.

The comments are simultaneously too verbose and not very helpful. They consistently refer to "writeback", which isn't mentioned anywhere else in iflib and only one or twice in the e1000 drivers. A couple of them imply that a queue being frozen for X timer periods is hung, but that's not true, as a different comment explains.

I see some failures in sys/capsicum tests too, sorry I missed those before.

I do not really understand why you moved the if_link_state_down() call out of gif_delete_tunnel(). Now SIOCDIFPHYADDR does not bring down the interface, isn't that a bug?

Nice! Mostly looks good, the only substantive comment is about the build integration.

Cast bytes to unsigned char, otherwise a negative byte will be sign
extended and occupy more than two bytes of the buffer.

Clean up KMSAN handling as well.

In D58552#1343760, @pouria wrote:

In D58552#1343759, @markj wrote:

This breaks the userspace ABI. Old ifconfig binaries won't work properly with a new kernel after this change.

I understand, that's why I said I can do it the other way.
I want to make sure it's needed, because users usually update their userland + kernel together.
So should I do it the other way?

This breaks the userspace ABI. Old ifconfig binaries won't work properly with a new kernel after this change.

Address Ryan's feedback

In D58271#1337325, @rlibby wrote:

I also wonder if we should have an option to add this redzone without KASAN. We could come up with a cheap-ish debugging feature to verify the redzone with uma_junk when we don't have KASAN. Not asking for that in this patch.