Thread (67 messages) 67 messages, 4 authors, 2021-04-23

Re: [PATCH v2 bpf-next 10/17] libbpf: tighten BTF type ID rewriting with error checking

From: Andrii Nakryiko <hidden>
Date: 2021-04-23 17:02:33
Also in: bpf

On Fri, Apr 23, 2021 at 9:34 AM Alexei Starovoitov
[off-list ref] wrote:
On Fri, Apr 23, 2021 at 9:31 AM Andrii Nakryiko
[off-list ref] wrote:
quoted
quoted
quoted
static int remap_type_id(__u32 *type_id, void *ctx)
{
        int *id_map = ctx;
        int new_id = id_map[*type_id];


/* Here VOID stays VOID, that's all */

        if (*type_id == 0)
                return 0;
Does it mean that id_map[0] is a garbage value?
and all other code that might be doing id_map[idx] might be reading
garbage if it doesn't have a check for idx == 0 ?
No, id_map[0] == 0 by construction (id_map is obj->btf_type_map and is
calloc()'ed) and can be used as id_map[idx].
Ok. Then why are you insisting on this micro optimization to return 0
directly?
That's the confusing part for me.
I'm not insisting:

  > but I'll rewrite it to a combined if if it makes it easier to follow

So I'm confused why you are confused.
If it was:
"if (new_id == 0 && *type_id != 0) { pr_warn"
Then it would be clear what error condition is about.
But 'return 0' messing things up in my mind,
because it's far from obvious that first check is really a combination
with the 2nd check and by itself it's a micro optimization to avoid
reading id_map[0].
I didn't try to micro optimize, that's how I naturally think about the
problem. I'll rewrite the if, don't know why we are spending emails on
this still.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help