linux-kernel - Re: [PATCH 3/3] kmemtrace: Use tracepoints instead of markers.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090102230116.GB5235@localhost>
Date:	Sat, 3 Jan 2009 01:01:17 +0200
From:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] kmemtrace: Use tracepoints instead of markers.

On Fri, Jan 02, 2009 at 03:53:45PM -0500, Mathieu Desnoyers wrote:
> * Eduard - Gabriel Munteanu (eduard.munteanu@...ux360.ro) wrote:
> >  
> > -#ifdef CONFIG_KMEMTRACE
> > -
> >  extern void kmemtrace_init(void);
> >  
> > -static inline void kmemtrace_mark_alloc_node(enum kmemtrace_type_id type_id,
> 
> Why do you need the enum kmemtrace_type_id type_id exactly ? Can you
> remove this parameter by adding more specific tracepoints ?
> 

Already done and moved that enum into the .c file. I've resubmitted the
whole thing (2 patches instead of 3). I'll provide an URL if you didn't get
those e-mails.

> > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> > index 7555ce9..e5a8b60 100644
> > --- a/include/linux/slab_def.h
> > +++ b/include/linux/slab_def.h
> > @@ -76,8 +76,9 @@ found:
> >  
> >  		ret = kmem_cache_alloc_notrace(cachep, flags);
> >  
> > -		kmemtrace_mark_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > -				     size, slab_buffer_size(cachep), flags);
> > +		trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > +				      size, slab_buffer_size(cachep),
> 
> You'll probably want to give "cachep" as parameter and do the
> slab_buffer_size(cachep) within the probe to remove unneeded code from
> the caller site.
> 

Hmm, I don't see how this could be an improvement. Slab code hackers are
supposed to see this and keep kmemtrace in line with slab internals.
Moving this away only makes things more awkward.

Besides, having a probe for each allocator and each function hardly
makes any sense.

Anyway, one could argue for an inline within slab code to handle such
internals, which does make more sense.

> > +				      flags, -1);
> >  
> >  		return ret;
> >  	}
> > @@ -134,9 +135,9 @@ found:
> >  
> >  		ret = kmem_cache_alloc_node_notrace(cachep, flags, node);
> >  
> > -		kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_,
> > -					  ret, size, slab_buffer_size(cachep),
> > -					  flags, node);
> > +		trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_,
> > +				      ret, size, slab_buffer_size(cachep),
> > +				      flags, node);
> >  
> >  		return ret;
> >  	}
> > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> > index dc28432..ce69c68 100644
> > --- a/include/linux/slub_def.h
> > +++ b/include/linux/slub_def.h
> > @@ -220,8 +220,8 @@ static __always_inline void *kmalloc_large(size_t size, gfp_t flags)
> >  	unsigned int order = get_order(size);
> >  	void *ret = (void *) __get_free_pages(flags | __GFP_COMP, order);
> >  
> > -	kmemtrace_mark_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > -			     size, PAGE_SIZE << order, flags);
> > +	trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC, _THIS_IP_, ret,
> > +			      size, PAGE_SIZE << order, flags, -1);
> 
> Same here for order.

Same goes here.

> Why do you need to pass -1 ? Can you have a more specific tracepoint
> instead ?
>

I've noticed probe functions tend to have really long names. -1 is just
very convenient, we could make it typo-proof by taking all negative values as
meaning "same node" in userspace, or clamp / warn about it in probes. Anyway,
I've seen SLOB does it in its inlines, e.g. kmem_cache_alloc() calls
kmem_cache_alloc_node(..., -1).

> >  
> >  	return ret;
> >  }
> > @@ -242,9 +242,9 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags)
> >  
> >  			ret = kmem_cache_alloc_notrace(s, flags);
> >  
> > -			kmemtrace_mark_alloc(KMEMTRACE_TYPE_KMALLOC,
> > -					     _THIS_IP_, ret,
> > -					     size, s->size, flags);
> > +			trace_kmemtrace_alloc(KMEMTRACE_TYPE_KMALLOC,
> > +					      _THIS_IP_, ret,
> > +					      size, s->size, flags, -1);
> >  
> 
> Pass s as parameter and do the s->size dereference within the probe.
> 
> The same applies to many other caller sites below.

Same as first comment, it would entail having specific kmemtrace
functions for specific allocator functions within specific allocators.


	Eduard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/