Alexei Starovoitov wrote:
On 3/1/18 12:51 AM, Naveen N. Rao wrote:
Daniel Borkmann wrote:
Worst case if there's nothing better, potentially what one could do in
bpf_prog_get_info_by_fd() is to dump an array of full addresses and
have the imm part as the index pointing to one of them, just
On 3/1/18 12:51 AM, Naveen N. Rao wrote:
Daniel Borkmann wrote:
On 02/27/2018 01:13 PM, Sandipan Das wrote:
With this patch, it will look like this:
0: (85) call pc+2#bpf_prog_8f85936f29a7790a+3
(Note the +2 is the insn->off already.)
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
Daniel Borkmann wrote:
On 02/27/2018 01:13 PM, Sandipan Das wrote:
With this patch, it will look like this:
0: (85) call pc+2#bpf_prog_8f85936f29a7790a+3
(Note the +2 is the insn->off already.)
1: (b7) r0 = 1
2: (95) exit
3: (b7) r0 = 2
4: (95) exit
where 8f85936f29a7790a is
On 02/27/2018 01:13 PM, Sandipan Das wrote:
> "Naveen N. Rao" wrote:
>> I'm wondering if we can instead encode the bpf prog id in
>> imm32. That way, we should be able to indicate the BPF
>> function being called into. Daniel, is that something we
>> can consider?
>
> Since each subprog does not
"Naveen N. Rao" wrote:
> I'm wondering if we can instead encode the bpf prog id in
> imm32. That way, we should be able to indicate the BPF
> function being called into. Daniel, is that something we
> can consider?
Since each subprog does not get a separate id, we cannot fetch
the fd and
