The biggest use case of AES-GCM is in the ipsec stack. Actually, that layer should be responsible for providing valid data to ossl. It is expected for the ossl function to fail if lengths are not aligned to block size (similar to what AES CBC does) as only the upper layers have the knowledge what algorithm has to be used for padding, if any. The AES-GCM RFC does not define any standard padding mechanism as this is the "stream encryption", but RFCs which make use of AES-GCM might have.

On arm64 we always use pcb->pcb_vfpsaved to find the correct state to use in context switch so make sure it is always valid (except in the savectx special case).
If you make sure the pcb_vfpsaved pointer is always valid, and call vfp_save_state where we are currently calling vfp_store the save side should work the same as on arm64. For restore you'll need to update vfp_bounce to handle a kernel VFP exception.

@andrew
Thanks for looking into it.
However, isn't that why we always pass ctx to fpu_kern_enter? In the end of that function (line 425) the vfpsaved pointer is swapped with ctx->prev which apparently should provide additional place for storing "old" vfp state. Therefore, in context switch any additional call to vfp_save_state should cause storing vfp state in temporary &ctx->state. Is it a case you were referring to?

Oh, I see now.
@sebastien.bini_stormshield.eu The best way to send patches to Phabricator is preparing them as diff-to-baseline (to main in this case). This way the most up=to-date patch contains all necessary changes. Phabricator will automatically handle all modifications in lines which had some todo/comment attached and mark those issues as resolved.

@sebastien.bini_stormshield.eu could you confirm if this changes still apply to HEAD? I was trying to find anything related to -oVERIFY in init.c but there is none such string. Is there anything missing which needs to be merged before this patch?

Are there any more issues to be resolved? Can we proceed with committing this patch?

I've updated the patch with epoch_wait changes.

Any comments here? I'd like to merge the code this week.

Rebased version.

Any comments?

It's not used on any official FreeBSD platform. However, with some out-of-tree BSPs this portion of code becomes active.

Are there any objections for this patch (+ all mentioned fixes)?

There is still a potential race between rip_detach and handling MRT_DONE (both call ip_mrouter_done). AFAIK these functions are not used at the same time so its highly unlikely this ever happen - I've never seen it so far.
I'm planning to further refactor ip_mroute.c to avoid this kind of issues, but not in this commit.

Thanks for comment, yes, the description might have been misleading.