A test case is for example trying to change the fib to use when forwarding a packet by the firewall.
Also the route need to point to an route that is marked down for some reason...(like interface is not in up state).
Load pf/ipfw and try changing the fib to be used with appropriate rules this will trigger the bug.

Since i wrote it!

Update to catch up with coments

It would be more visible if you take this into consideration https://reviews.freebsd.org/D3022

Will submit a new update taking into consideration comments.

Really this is a weird use case though the expiry will not be supported on SPD but SAs will still be the same way usable.
The code also needs a follow-up patch to properly make the SPD matched only by the socket that configured from the policy, today code tries to do something that i am almost complete its broken in behaviour by overriding the policy that might have been applied from application.

Confirmed this fixes the issue from PR reporter.

This was identified during analysis of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201371

Apart the pause its OK.

In D2986#59244, @ae wrote:

In D2986#59234, @eri wrote:

I also understand that this code path also has the purpose of trying to check if the full policy has been applied to the packet but it skips some locking and its not correct, just that the issue is not hit often since SPDs/ISR on IPSEC do not get modified very often as they are read-mostly properties.

Each consumer of SPD entry holds reference to SPD, and there is no way to modify SPD entry. You only can unlink existing entry from the chain and add new entry. So, I don't see the problem here. The main problem is with locking of SAD and ISRs.

So you are saying someone will only create a IN SP for just discarding packets without any ipsec policy in place?
Sounds like a very weird scenario when the user can just load a module in previous versions of FreeBSD for firewalling!

Another update by doing the search on the incoming policies only if there is one outgoing.

Andrey what is the use case for that?

Simplify logic in ip6_forward.c code by gathering the whole code under the same IPSEC ifdef.
This also allows next change on moving all these code to IPSEC specifc files and helps for the goal of having IPSEC as module.

Somehow the revision is not closed automatically when setting the editing only to source committers.
Do this manually.

After more testing, with help of Olivier, keep the workaround of testing if any SP is present to not impact general forwarding in non-IPSEC usage case.

Correct paramter on ip_ipsec to ipsec_in_reject

Increment can't forward counter only for forwarded packets.

So ae@ do you approve this diff to push it?

Yes application can put some SPDs.
The PCB is used as a cache for better performance but really not much gain there since it complicates the code and scenarios needed to be considered.
For me the link can be broken and everything treated as in the forwarding path!

Yes, you are right that this is a workaround.

ae@ i think i spotted the only reference leak i missed.
If not, can you be more verbose?

The only issue i have with jmg@ locking patch is that it provides consistency for userland threads but i still do not see how it solves the panic due to FPU on a migrated thread!

Update to take into account the comments on malloc casting and removing bzero().
Added the changes to altq(4) manual page.

In D2847#55014, @hiren wrote:

In D2847#54917, @eri wrote:

This is in part of the work for code reduction and patches import from pfSense.
Next will come CodelQ scheduler implementation.

Is that also going to come from DragonFlyBSD?

Remove spl(9) and MALLOC/FREE

This is in part of the work for code reduction and patches import from pfSense.
Next will come CodelQ scheduler implementation.

In D2566#48206, @ae wrote:

Did you test functionability of this AES-GCM implementation with other systems that already have implemented AES-GCM in IPSec? AFAIK, OpenBSD and Linux have it.

Can you please not commit this.
I have a patch which does all of this and more, including using AES-NI for IPsec.