Hi! Writing this with my core@ (and srcmgr@) lurker hat on.

I don't see a point in clearing the addresses either. Speculatively (didn't check!) it should even fix getsockname(2) on a disconnected TCP connection.

• Apply Kostik's & Mark's suggestions

Today was my turn to be stupid :) See 430df2abee9049c2e4773704190a9f0d1779ff10

Alternatively the entire function can be rewritten in declarative manner:

	const struct ip6_hdr *ip6 = mtod(m, struct ip6_hdr *);
	struct ip6_hdr_pseudo ip6ph = {
		.ip6ph_src = ip6->ip6_src,
		.ip6ph_dst = ip6->ip6_dst,
		.ip6ph_len = htonl(m->m_pkthdr.len - (ip6->ip6_nxt == IPPROTO_UDP ? sizeof(struct ip6) + sizeof(struct udphdr) : sizeof(struct ip6)),
		.ip6ph_nxt = htonl(IPPROTO_TCP),
	};

• Remove unneeded extern.
• Remove all comments that talk about userret().
• Remove atomics from module unload, they don't make it safe, just pretend.

@ivy any ideas how to keep tests/sys/netinet/carp.sh working without routed?

Bruce, to be more specific: this particular change needs to add only destroy_policy_queue() and don't do anything wrt the locks. Then a separate change that moves lock initialization to ip6_init() is possible.

In D55599#1272620, @pouria wrote:

In D55599#1272617, @glebius wrote:

A general rule of thumb: you ever want to use IS_DEFAULT_VNET(curvnet) in some stub network module - you are doing something wrong :)

Noted. Thanks for explaining.

This can't be correct cause now rt_get_rnd() may receive a NULL argument and inside it definitely dereferences it.

This is not correct VNET-wise. A general rule of thumb: you ever want to use IS_DEFAULT_VNET(curvnet) in some stub network module - you are doing something wrong :)

I don't feel myself expert enough to neither endorse or veto the update. In general I am of course in favor of being up to date with this library.

Do you plan to rebase that over removal of IFP_TO_IA() in preference to in_ifprimaryaddr()?

P.S. I would suggest to retitle to netinet: introduce in_ifprimaryaddr() to lookup first IPv4 address of an ifnet. IMHO, there is not reason to reference a macro that is about to go away.

I added some suggestion, but they are IMHOs. I'd suggest to wait for approval from a doc committer. @ziaee maybe you?

In D48709#1269030, @pouria wrote:

Are you still working on this? @glebius
if that's the case, Could you please set the planned change state for this revision?

I'd suggest to change to title to explictily say "TCP over UDP", cause "TCP/UDP" can be misinterpreted to a change to TCP and a similar change to UDP.

LGTM module suggestions made in D55344.

I agree that not much left of ifcreate_nl() and it can be inlined into ifgeneve.c.

The ndq_refcount seems to be not really used. Could it be you wanted to use to to have the callout to refcount the ndq?

Immediately caught in bridge(4):

NET_EPOCH_ENTER(et);

Sorry for making the Geneve check-in process longer, but I really want to understand all corner cases, instead of workarounding them.

No objection for MFC. Neither encouragement, though :)

Not an expert in the area, but code wise LGTM.

In D55174#1263726, @pouria wrote:

After running my tests for this change, I remembered that
the netlink can reply with an NLMSG_ERROR containing error = 0.

I'd suggest to commit all comments and whitespace changes that can be committed without breaking down nd6_ra_input() separately. That will make meaningful diff smaller. btw, it is great putting references to RFC before important actions and checks!

Sorry, missed the if (nbio == 0)

Can you please rebase? There is no longer ND_IFINFO().

Also (NETLINK) isn't a great error message at all. Please try grep errx sbin/ifconfig/*.c to check other error messages. Maybe just only contents of errmsg.error_str in the case it was provided and unknown error from netlink(4) in case it was not?

No objections from me, I rather agree. But I am not enough expert in IPv6 to make a strong judgement on defaults change.

Merge this original diff + Warner's D55107 together.

Sorry, I didn't ask to de-virtualize the queue, only the lock. I actually asked why can't we hang off the queue from the in6_ifaddr instead of making it global? btw, how many queue entries per unique address could be there?

Approved, but please address comment in the module event switch statement.

Please consider all trivial MFCs approved.

I can't understand the problem. If structure is known sizeof(*ext) results in the same value as sizeof(struct HDB_extension). If the structure is not known and has only forward declaration, compilation should fail with: invalid application of 'sizeof' to an incomplete type.

For such a test you'd better move one of the interfaces into VIMAGE jail. This will isolate not only from this particular problem, but from other potential problems.