Jordan Rome

There also might be plans to have a bpf ring buffer that overwrites old data, which could be used for this.

> Perhaps it was inlined? You can check this with `llvm-dwarfdump` (I can't recall if you can also get this from `objdump`) and look for the inline tag `DW_TAG_inlined_subroutine` e.g....

Hmm, it doesn't look like it's inlined but just to double check try this: ``` $ llvm-dwarfdump ~/.cache/debuginfod_client/3edee3fb40fd1b126fc72a33a90d2abb7aabe46a/debuginfo | grep -A 5 DW_TAG_inlined_subroutine ```

Yah I don't see that function in the output so I feel like function inlining is not the problem.

While it would be great to re-use `ustack` and `kstack`, I'm wondering if that's going to prove difficult as we have to use a different method for getting task stacks...

Just to note: `bpf_get_task_stack` does not allow retrieving user stacks for any task that isn't the current one. There is a way to get the user stacks from non current...

My first guess is that function was inlined. Can you try running this against both vmlinux binaries? `llvm-dwarfdump /path/to/vmlinux | grep -A 5 DW_TAG_inlined_subroutine | grep -C 1 nf_nat_ipv4_manip_pkt`

@pkopensrc Are you able to duplicate this behavior with a raw bcc or libbpf program? Then at least we'd know if it is isolated to bpftrace.

> Libbpf i tried and it failed Ah interesting. I wonder if the bug is in bpftrace's listing of kprobes that are not actually available to attach to. I'll see...

@pkopensrc Mind trying one more thing, can you run this on both kernel versions? `sudo cat /sys/kernel/debug/tracing/available_filter_functions | grep "nf_nat_ipv4_manip_pkt"`