Hi Kumar,
Sorry for delayed response. Theoretical possibility that frame merge
might fail because of some e.g. clang version changes bugs me,
so I thought a bit on what alternatives are there.
For the sake of discussion, what do you think about runtime-based
approach:
- for each throwing sub-program reserve a stack region where
references to currently acquired resources (and their types)
would be stored;
- upon a call to something that acquires resource push pointer/type
pair to this region;
- upon a call to something that releases resource delete pointer/type
pair from this region;
- when bpf_throw() is executed, walk this region for each active frame
and execute corresponding destructors.
- (alternatively, reserve one region for all frames).
Technically, this could be implemented as follows:
- during main verification pass:
- when verifier processes a call to something that acquires resource,
mark call instruction and resource type in insn_aux_data data;
- same for processing of a call to something that releases resource;
- keep track of a maximal number of simultaneously acquired resources;
- after main verification pass:
- bump stack size for each subprogram by amount, necessary to hold
the acquired resource table and assume that this table is at the
end of the subprogram stack;
- after each acquire call, insert a kfunc call that would add
resource reference to the table;
- after each release call, insert a kfunc call that would remove
resource reference from the table.
On a surface it appears that this approach has a few advantages:
- seems simpler than frame descriptors tracking and merging
(but only implementation would tell if this is so);
- should be resilient to program compilation changes;
- abort is possible at any program point, which might be interesting for:
- cancelable BPF programs (where abort might be needed in the middle
of the e.g. loop);
- arenas, where it might be desirable to stop the program after e.g.
faulting arena access.
The obvious disadvantage is incurred runtime cost.
On the other hand, it might be not that big.
What do you think?
Thanks,
Eduard
