From: Alexei Starovoitov Date: Sat, 25 Mar 2023 23:56:22 +0000 (-0700) Subject: Merge branch 'Don't invoke KPTR_REF destructor on NULL xchg' X-Git-Tag: v6.4-rc1~77^2~118^2~61 X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=496f4f1b0f8e01baea22e6573f60af8cfd84df48;p=tomoyo%2Ftomoyo-test1.git Merge branch 'Don't invoke KPTR_REF destructor on NULL xchg' David Vernet says: ==================== When a map value is being freed, we loop over all of the fields of the corresponding BPF object and issue the appropriate cleanup calls corresponding to the field's type. If the field is a referenced kptr, we atomically xchg the value out of the map, and invoke the kptr's destructor on whatever was there before. Currently, we always invoke the destructor (or bpf_obj_drop() for a local kptr) on any kptr, including if no value was xchg'd out of the map. This means that any function serving as the kptr's KF_RELEASE destructor must always treat the argument as possibly NULL, and we invoke unnecessary (and seemingly unsafe) cleanup logic for the local kptr path as well. This is an odd requirement -- KF_RELEASE kfuncs that are invoked by BPF programs do not have this restriction, and the verifier will fail to load the program if the register containing the to-be-released type has any untrusted modifiers (e.g. PTR_UNTRUSTED or PTR_MAYBE_NULL). So as to simplify the expectations required for a KF_RELEASE kfunc, this patch set updates the KPTR_REF destructor logic to only be invoked when a non-NULL value is xchg'd out of the map. Additionally, the patch removes now-unnecessary KF_RELEASE calls from several kfuncs, and finally, updates the verifier to have KF_RELEASE automatically imply KF_TRUSTED_ARGS. This restriction was already implicitly happening because of the aforementioned logic in the verifier to reject any regs with untrusted modifiers, and to enforce that KF_RELEASE args are passed with a 0 offset. This change just updates the behavior to match that of other trusted args. This patch is left to the end of the series in case it happens to be controversial, as it arguably is slightly orthogonal to the purpose of the rest of the series. ==================== Signed-off-by: Alexei Starovoitov --- 496f4f1b0f8e01baea22e6573f60af8cfd84df48