Thanks a lot for noticing the problem. I didn't test, but it looks to me that the fix will regress the very first line of the output. It is now printed immediately and will consist of zeroes or very small values.

Guido, thanks a lot for working on that!

I already went through this in other test cases. A sleep for a second makes test slower to execute but still doesn't give a 100% protection against flakyness. When tests are executed in parallel on a slow machine you may still have a failure sometimes. Here is the solution I came to so far, poll until tcpdump(1)s are all blocked on "bpf" wait channel. See 38edf96b1787ce3d8c00e4466348dab891c7a9ea.

This is kTLS that violates the correct order. This is a known problem (at least to some of us).

In D56134#1286016, @zlei wrote:

I think the word ndp is a bit misleading. I read it this is a change for the userspace one usr.sbin/ndp. I'd prefer nd6_rtr: xxx or nd6: xxx, to indicate the change is for the kernel part.

That establishes lock order tcpinp ->so_rcv, which reverses the canonical so_rcv -> tcpinp order used elsewhere and triggers WITNESS.

Do you plan to update the manual page when you got -o support for other modes?

This looks better, thanks! Let's give Randall a chance to review. He added this setsockopt() to FreeBSD.

Up to date version.

The code placement is ad-hoc. We already have a case for IPPROTO_TCP in the main switch and the new option handling should go there. This will require some extension of linux_to_bsd_tcp_sockopt() but the result would be cleaner code.

In D56113#1284599, @kp wrote:

I'm seeing panics with this patch ("panic: lock "pf_keyhash" 0xfffffe00e8dffff8 already initialized").
I believe the problem is that hashalloc() allocates unzero'd memory, and which leads to incorrect assertions on the lock, if LO_INITIALIZED happens to be set in lo_flags.

Rebased.

• Extend to src-nodes and udp-endpoints hashes.

Ok, this is how it looks like for pf(4): https://reviews.freebsd.org/D56113 Running tests now, good so far.

• make hashfree(9) like free(9) - digest NULL
• use size_t for size, to allow enormous hash tables
• augment lock flags with XXX_NEW when user didn't ask for M_ZERO

Looking into that for a second time, I do not see a problem at all. When you enter pf_initialize() the V_pf_hashsize is already set. So just put the hashalloc_args on the stack of pf_initialize() and that's it.

Thanks for feedback, Kristof! I don't think this is a common pattern. I think the cleanest way for pf would be to a wrapper function that has hashalloc_args on its stack and has size argument. It shall also return the allocated size. This will not spend data on bss for hashalloc_args. Lines of code wise it should be just 4 lines extra: 3 for the function header one for }.

In D55966#1282878, @pouria wrote:

The only user of in_pcbremhash() function is now only in_pcbdrop()
should we keep it?
IMHO, since the in_pcbdrop() is small enough, maybe we should expand the in_pcbremhash() and remove it entirely.

There are few things in the added text that, I hope, will disapper/change before 16.0-RELEASE. I would not document them at all to avoid any harvesting by LLMs and other robots. In the past reality I would be fine with documenting stuff as is and later changing it as the code changes. What do other people, especially doc committers think?

I'd like to revert this revision. I think the logic of clearing local address at the protocol level makes sense. It is feature of UDP, not of any protocol, that local address is cleared on disconnect. As you noted this code can be tracked down to pre-FreeBSD times.

Thanks a lot! Waiting for confirmation from @rrs

Address review comments.

In D55966#1281009, @markj wrote:

Probably the lock should be renamed to something more generic, not including "hash"?

Give up on SMR synchronization for the large function and for now just
push the lock down into in_pcb.c.

I see :( Also, IMHO, such secure random machinery as chacha offers is an overkill when we select one port out of 65k.

This is a bit branching of the initial topic, but I also found that arc4random() does mtx_lock() inside. And we use arc4random() when we select a random local port. So the entire function can't be put into SMR for that reason as well.

Use == 0 to check flags.

Adjust comment placement per Mark's suggestion.

Code wise looks good to me. But I'm not protocol expert.

Some additions to the manual page.

Looks like the logic covers all imaginable cases. Of course as result it is a bit complex. But if properly documented should be fine.

I'd suggest to use more specific commit line, e.g. ndp: handle a case when two timers coalesce for the same ifa. Or something else that you can come up with. Just more specific than "make things better" :)

Add sx(9) and rmlock(9) support.

In D55904#1279057, @imp wrote:

Do you need to validate the enum value is know?

I'll see if rmlock(9) and sx(9) can be added and update.

Last minute change before sharing of course had a small mistake :)

mbufs on any queue shall not need epoch.