cleanup(bpf): reduce preemption fragility in overlayfs dedup

[Stringy]

Description

The whole chain is in a single syscall context:
overlayfs -> open (first call to lsm hook) -> underlying fs -> open (second call to lsm hook.)

But the kernel thread might be preempted between the two lsm calls, resulting in scheduling on a different CPU and causing a cache miss when deduplicating overlayfs events.

To reduce this risk, this PR changes the dedup map to a global (not PERCPU) LRU map with 256 entries.

Checklist

• Investigated and inspected CI test results
• Updated documentation accordingly

Automated testing

• Added unit tests
• Added integration tests
• Added regression tests

If any of these don't apply, please comment below.

Testing Performed

CI should be enough.

[Molter73]

What happens if the kernel decides to run a separate program that also attempts to access an overlayfs file between the two separate calls to file_open? Will the call just fail to add the entry on the map and produce the duplicate event we stopped with the fix? Can this even happen or is the two calls to file_open happening during the same syscall in a way that prevents the program from being preempted?

I'm just trying to understand if the right move is having a single entry per CPU or if we should have an LRU with multiple entries.

[Stringy]

I had originally thought that this is safe because the whole chain is in a single syscall context:
overlayfs -> open (first call to lsm hook) -> underlying fs -> open (second call to lsm hook.)

But having said that you might be right that the kernel could be preempted between those two calls; so the kernel is scheduled on a different CPU and misses the cache, and we'd emit the duplicated event. LRU cache + some arbitrarily sensible number of entries? 256?

[Molter73]

LRU cache + some arbitrarily sensible number of entries? 256?

Yeah, but it needs to be a regular (non-per-cpu) map, otherwise it will still fail when preempted, just so we are 100% clear on this.

[Molter73]

LGTM!