ifnet: if_vmove_(loan|reclaim): Refactor a bit the checking of src / dst vnet

[zlei]

Summary

The if_vnet of interface is lacking synchronization, thus it is a bit
trick to access it. Refactor a little to exhibit the intention clearly.

MFC after: 2 weeks

[jamie]

sys/net/if.c

1203

Since if_vmove passes ifp and pr, it feels more intuitive to compare the vnets from ifp and pr, rather than td and pr. That also goes back to the idea of an assertion than td and ifp are always in the same vnet.

[zlei]

sys/net/if.c

1203

The tricky part is that ifp is lacking proper locking, thus ifp->if_vnet is not stable. So it is possible that MAPSS(ifp->if_vnet == TD_TO_VNET(td) will fail.

The ifp is intitially obtained from current thread ( td ), but due to racing, unlink it from current "active" ifnet list may fail, see the following logic,

	found = if_unlink_ifnet(ifp, true);
	if (! found) {
		sx_xunlock(&ifnet_detach_sxlock);
		prison_free(pr);
		return (ENODEV);
	}

So a stable way to check if we are moving the iface from and to the same vnet is not refer to ifp->if_vnet, but TD_TO_VNET(td) .

[zlei]

Superseded by D55880.

sys/net/if.c

1203

Since if_vmove passes ifp and pr, it feels more intuitive to compare the vnets from ifp and pr, rather than td and pr. That also goes back to the idea of an assertion than td and ifp are always in the same vnet.

I'm abandoning this revision, superseded by D55880. The latter should show the logic clearly.

[zlei]

In D55832#1278488, @zlei wrote:

Superseded by D55880.

by D55880 and D55898 .