Neil Horman
Neil Horman
I see what that is saying, but I can't seem to reconcile it with what the compiler produces. on aarch64, CRYPTO_DOWN_REF emits this: ``` static inline int CRYPTO_DOWN_REF(CRYPTO_REF_COUNT *refcnt, int...
I'm not sure I follow you there @kroeckx , its the only call in that function to the atomic fetch_add routine there, so I'm not sure how it could be...
yeah, thats the issue, heres the full output: ``` void ThreadProc(atomic& counter) { 400c44: a9bc7bfd stp x29, x30, [sp, #-64]! 400c48: 910003fd mov x29, sp 400c4c: f9000fe0 str x0, [sp,...
@MBkkt can you test with the associated PR please, and confirm that it fixes the issues you've encountered?
I'm fine with the piggy-back CI errors look unrelated
Marking as inactive, to be closed at the end of 3.4 dev barring further input
the oscp responder should work @andrejpodzimek as far as I know. If you are having independent issues with it, please open a separate issue and we will investigate
can we add a test for this in quicapitest, in which the mdpl is increased, so we're sure the bug is fixed?
Looks like you need a rebasee, but otherwise, LGTM
@levitte could you please inviestigate this and propose a solution to the issue as described?