Re: [PATCH bpf-next v2] bpf: support raw tracepoints in modules

[Martin Lau]

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@xxxxxx>

[ ... ]

> > > +#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.