Can you verify that the LINT kernel passes with this change on aarch64?

Commit message should be something like this:
Enable ioremap for aarch64 in the LinuxKPI.

@glebius: I believe all the alternatives for solving this issue has been enumerated and discussed.

Can you split this patch?

@johalun: can you try again with the dma_lock changes?

Can you test ifconfig adding / removing and setting same ipv4 multicast address and ensure you don't leak by printing the refs involved?
Also can you do the same for starting and stopping rpcbind?

When committing and MFC-ing this patch you'll need to bump the __FreeBSD_version in sys/sys/param.h, because you are changing fundamental structures and external kernel modules needs to be rebuilt.

Do I get an accept from transport aswell?

Looks good.

The latter in6m_acquire(in6m) should also be removed from carp driver. I think this is a bug. Can you test?

Are you trying to mimic the solution I did for IPv6 MLD?

Is it possible to fix PF and CARP instead? Allocating an INM with an initial refcount of 2 seems a bit odd!

What kind of tests have been done in order to check for leaks?

@johalun : I'd like to have you test these patches with drm-next before going upstream. Can you do that?

Fix eventhandler function arguments. Apparently there was no compiletime check for the prototype.

I've had another go at this and it appears only IPv4 and IPv6 fragments cause use-after free and panic.
I've narrowed down my patch to be more specific.

The patch technically looks good to me. Is this change for MFC only?

@glebius and @hselasky rather than changing pr_drain I wondered about an eventhandler or something as that way dealing with non-protocol places such as firewalls, netisr, .. would also be possible? I think not queuing is not an option, arp queue is just another one of these places... there's more and more the longer I think about it... We'll need something to get them all (and getting the locking right).