A question about the AF_PACKET TPACKET_V3 implementation

Developers
1

Hi,

While reading the AF_PACKET TPACKET_V3 implementation in Suricata,I have a question and hope to gain some insight

In AFPReadFromRingV3(), the ownership of a block is returned to the kernel by writing:

pbd->hdr.bh1.block_status = TP_STATUS_KERNEL;

and block readiness is checked by directly reading block_status.

I noticed that libpcap introduced acquire/release semantics for the same ownership transfer in the following commit:

using __atomic_load_n(..., __ATOMIC_ACQUIRE) and __atomic_store_n(..., __ATOMIC_RELEASE).

I was wondering whether Suricata intentionally relies on plain loads/stores here, or whether there are assumptions about the AF_PACKET implementation that make explicit acquire/release semantics unnecessary.

It’s entirely possible that I’m missing some background or historical context, so I’d appreciate any insight into the reasoning behind the current implementation.

I’d appreciate any explanation or pointers if this has already been discussed.

Thank you!

2

Hi Jal,

Considering the age of the code (contributed 12 years ago), I don’t think there is a particular reason why it is like that.

If I understand that correctly, the right solution would be to change the access to atomic, as there is a potential for concurrent edits by kernel/application threads?

Thanks.