On 26/09/2023 11:44, Zachary Leaf wrote:
+#define bpf_field_exists(uattr_size, field) \
The naming is a bit strange, though to be fair it's not easy to come up with something meaningful. Maybe bpf_has_field?
There is some precedent in libbpf/userspace, see tools/lib/bpf/bpf_core_read.h - there's bpf_core_field_exists() to check a similar thing but the other way around i.e. userspace checks if kernel has a field.
This is the exact opposite, kernel is checking if userspace has a field.
Also see: https://nakryiko.com/posts/bpf-core-reference-guide/#bpf-core-field-exists
Fair enough, makes sense to reuse that naming.
- (in_compat_syscall() ? \
(uattr_size >= offsetofend(union compat_bpf_attr, field)) : \(uattr_size >= offsetofend(union bpf_attr, field)))typedef u64 (*bpf_callback_t)(u64, u64, u64, u64, u64); typedef int (*bpf_iter_init_seq_priv_t)(void *private_data, struct bpf_iter_aux_info *aux); diff --git a/include/linux/bpfptr.h b/include/linux/bpfptr.h index 79b2f78eec1a..7fdf9692d76e 100644 --- a/include/linux/bpfptr.h +++ b/include/linux/bpfptr.h @@ -8,6 +8,14 @@ typedef sockptr_t bpfptr_t; +#define __bpfptr_put_uattr(type, x, uattr, to_field) \
- (copy_to_bpfptr_offset(uattr, offsetof(type, to_field), &x, sizeof(x)))
+#define bpfptr_put_uattr(x, uattr, to_field) \
The order of arguments should probably be the same in both bpf_put_uattr() and bpfptr_put_uattr(). I'm not sure which makes more sense, both look plausible.
Better to make it match closer with put_user() I think, since that is what it's trying to replicate
e.g.
- if (put_user(0, &uattr->batch.count))
- if (bpf_put_uattr(0, uattr, batch.count))
I agree, that feels most natural.
Kevin