Hi Christian, I don't think you have missed anything, as far as I can tell it is a bug. Wondering how it is done in the non-DPDK case with handoff. I don't know the handoff internals but from a quick glance, and I might be wrong here, it seems that you would run into a similar situation.
Cheers, Sergio On Mon, Mar 2, 2020 at 8:49 PM Christian Hopps <cho...@chopps.org> wrote: > 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 (#15667): https://lists.fd.io/g/vpp-dev/message/15667 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] -=-=-=-=-=-=-=-=-=-=-=-
