Messages in this thread | | | From | Martin Lau <> | Subject | Re: [PATCH bpf-next v2] bpf: support raw tracepoints in modules | Date | Thu, 13 Dec 2018 21:11:22 +0000 |
| |
On Thu, Dec 13, 2018 at 11:38:51AM -0800, Matt Mullins wrote: > On Thu, 2018-12-13 at 19:22 +0000, Martin Lau wrote: > > On Wed, Dec 12, 2018 at 04:42:37PM -0800, Matt Mullins wrote: > > > Distributions build drivers as modules, including network and filesystem > > > drivers which export numerous tracepoints. This enables > > > bpf(BPF_RAW_TRACEPOINT_OPEN) to attach to those tracepoints. > > > Acked-by: Martin KaFai Lau <kafai@fb.com>
[ ... ]
> > > +#ifdef CONFIG_MODULES > > > +int bpf_event_notify(struct notifier_block *nb, unsigned long op, void *module) > > > +{ > > > + struct bpf_trace_module *btm, *tmp; > > > + struct module *mod = module; > > > + > > > + if (mod->num_bpf_raw_events == 0 || > > > + (op != MODULE_STATE_COMING && op != MODULE_STATE_GOING)) > > > + return 0; > > > + > > > + mutex_lock(&bpf_module_mutex); > > > + > > > + switch (op) { > > > + case MODULE_STATE_COMING: > > > + btm = kzalloc(sizeof(*btm), GFP_KERNEL); > > > + if (btm) { > > > + btm->module = module; > > > + list_add(&btm->list, &bpf_trace_modules); > > > + } > > > > Is it fine to return 0 on !btm case? > > That effectively just means we'll be ignoring tracepoints for a module > that is loaded while we can't allocate a bpf_trace_module (24 bytes) to > track it. That feels like reasonable behavior to me. ok.
| |