On Fri, 2024-02-16 at 23:28 +0100, Kumar Kartikeya Dwivedi wrote: [...] > > Question: > > Maybe I missed something in frame descriptor construction process, > > but it appears like there is nothing guarding against double cleanup. > > E.g. consider a program like below: > > > > r6 = ... PTR_TO_SOCKET ... > > r7 = r6 > > *(u64 *)(r10 - 16) = r6 > > call bpf_throw() > > > > Would bpf_cleanup_resource_reg() be called for all r6, r7 and fp[-16], > > thus executing destructor for the same object multiple times? > > Good observation. My idea was to rely on release_reference so that > duplicate resources get erased from verifier state in such a way that > we don't go over the same ref_obj_id twice. IIUC, we start from the > current frame, and since bpf_for_each_reg_in_vstate iterates over all > frames, every register/stack slot sharing the ref_obj_id is destroyed, > so we wouldn't encounter the same resource again, hence the frame > descriptor should at most have one entry per resource. We iterate over > the stack frame first since the location of registers holding > resources is relatively stable and increases chances of merging across > different paths. Oh, right, thank you for explaining. At first I thought that release_reference is only for verifier to keep track if there are some resources that bpf_throw() can't cleanup at the moment.
