So this came up in another thread for a question I had about locking, but I didn't want the point to get lost since a lot of other things were discussed.
When an SA is deleted it is done from an API that is not marked mp safe, therefore it is done with the worker thread barrier. The ipsec code then assumes it is safe to delete the SA data, and does so. However, packets associated with the now deleted SA may exist in the middle of traversing the node graph on the dpdk crypto offload device queue. So, after the SA is deleted and the API releases the barrier, the crypto-input polling node will start running again, dequeueing newly decrypted (or encrypted) packets and injecting them back into the node graph. I believe this is a problem e.g., taking a look at https://github.com/FDio/vpp/blob/master/src/plugins/dpdk/ipsec/esp_decrypt.c#L543 This is extracting the sa_index from the buffer, getting a pointer to the data and then acting on it. In fact, this SA (pool element) may no longer be valid, or it may have been re-used at this point. Is this a bug, or have I missed something? Thanks, Chris.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15662): https://lists.fd.io/g/vpp-dev/message/15662 Mute This Topic: https://lists.fd.io/mt/71683366/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
