Hi Daniel,
Thanks for the follow up.
On 08/05/2015 10:33 PM, Daniel Borkmann wrote:
> On 08/05/2015 10:09 PM, Michael Kerrisk (man-pages) wrote:
> ...
>>> +returning back.
>>> +The level of nesting has a fixed limit of 32, so that infinite loops cannot
>>
>> Where is that limit of 32 defined, by the way?
>
> Currently, an implementation detail in the kernel, so not exposed under uapi.
> It's MAX_TAIL_CALL_CNT in include/linux/bpf.h.
Thanks, I dropped a comment into the page source.
>>> +be crafted.
>>> +During runtime, the program file descriptors stored in that map can be modified,
>>> +so program functionality can be altered based on specific requirements.
>>> +All programs stored in such a map have been loaded into the kernel via
>>> +.BR bpf ()
>>> +as well.
>>> +In case a lookup has failed, the current program continues its execution.
>>
>> What are the possible causes of failure? It may be worth saying something about
>> this in the man page.
>
> That the map slot doesn't contain a program file descriptor, that the
> used lookup index/key is out of bounds, or that we've exceeded the maximum
> nesting (MAX_TAIL_CALL_CNT).
Okay thanks. See below.
>> (For future patches, please start new sentences on new lines.)
>
> Okay, I guess I still have to get used to it, sorry.
>
>>> +A program array map is a special kind of array map, whose map values only
>>> +contain valid file descriptors to other eBPF programs. Thus both the
>>> +key_size and value_size must be exactly four bytes.
>>> +This map is used in conjunction with the
>>> +.BR bpf_tail_call()
>>> +helper.
>>
>> Is this caller already in mainline? I could not find it in the current rc?
>
> It's since commit 04fd61ab36ec ("bpf: allow bpf programs to tail-call other
> bpf programs").
Got it. (I thought I was looking in the -rc before, but I was confused.)
>>> +and therefore replace its own program flow with the one from the program
>>> +at the given program array slot if present. This can be regarded as kind
>>> +of a jump table to a different eBPF program. The invoked program will then
>>> +reuse the same stack.
>>
>> Are there any implications of the fact that it uses the same stack
>> that should be mentioned in the man page?
>
> Due to the stack reuse better performance.
Okay.
>>> When a jump into the new program has been performed,
>>> +it won't return to the old one anymore.
>>> +
>>> +If no eBPF program is found at the given index of the program array,
>>
>> I find this language a little unclear. The array does not contain eBPF
>> programs, but rather file descriptors. So, what does "not found" here
>> really mean? (I added a FIXME.)
>
> Ok, it's a bit more complicated to explain I guess. So from user space
> side, a lookup on that map type is not allowed. When user space adds a
> new file descriptor into the prog map, the kernel internally translates
> that to the actual program holds reference, etc. The tail call helper is
> mapped into a eBPF instruction, so no real helper call here. That instruction
> will then have a register setting as if we'd have a function call, so it
> has the lookup key and uses it directly to find the array slot. From
> there, it has access to the actual underlying program. "Not found" means
> conditions mentioned as earlier above.
Okay I've changed that paragraph to now read:
If no eBPF program is found at the given index of the pro‐
gram array (because the map slot doesn't contain a valid
program file descriptor, the specified lookup index/key is
out of bounds, or the limit of 32 nested calls has been
exceed) execution continues with the current eBPF program.
This can be used as a fall-through for default cases.
Okay?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
