linux-kernel - Re: [RFC][PATCH 02/10] tracing: Allow for modules to export their trace enums as well

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]

Date:	Mon, 30 Mar 2015 09:48:02 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [RFC][PATCH 02/10] tracing: Allow for modules to export their
 trace enums as well

On Mon, 30 Mar 2015 11:41:00 +0900
Namhyung Kim <namhyung@...nel.org> wrote:


> > + * The trace_enum_maps are saved in an array whith two extra elements,
> 
> s/whith/with/

Heh, thanks for catching that.

> 
> > + * one at the beginning, and one at the end. The beginning item contains
> > + * the count of the saved maps (head.length), and the module they
> > + * belong to if not built in (head.mod). The ending item contains a
> > + * pointer to the next array of saved enum_map items.
> > + */
> > +union trace_enum_map_item {
> > +	struct trace_enum_map		map;
> > +	struct trace_enum_map_head	head;
> > +	struct trace_enum_map_tail	tail;
> > +};
> > +
> > +static union trace_enum_map_item *trace_enum_maps;
> >  
> >  static int tracing_set_tracer(struct trace_array *tr, const char *buf);
> >  
> > @@ -3911,29 +3942,47 @@ static const struct file_operations tracing_saved_cmdlines_size_fops = {
> >  	.write		= tracing_saved_cmdlines_size_write,
> >  };
> >  
> > +static union trace_enum_map_item *
> > +update_enum_map(union trace_enum_map_item *ptr)
> > +{
> > +	if (!ptr->map.enum_string) {
> > +		if (ptr->tail.next) {
> > +			ptr = ptr->tail.next;
> > +			ptr++;
> 
> I guess this additional increment is to skip head item.  Maybe it
> deserves a comment. :)

Yep it does. I'll add one.

> 
> 
> > +		} else
> > +			return NULL;
> > +	}
> > +	return ptr;
> > +}
> > +
> >  static void *enum_map_next(struct seq_file *m, void *v, loff_t *pos)
> >  {
> > -	struct trace_enum_map *ptr = v;
> > +	union trace_enum_map_item *ptr = v;
> >  
> > -	if (!ptr->enum_string)
> > +	ptr = update_enum_map(ptr);
> 
> Again, is this necessary?

Not really, but I'm doing it to be paranoid. If for some reason 'ptr'
is at the tail end (which it should never happen), then the increment
below will cause an invalid pointer dereference.

I should at least add a comment here saying I'm being paranoid. It's
far from a fast path so I don't really care about slowing things down
here to be extra safe.

> 
> 
> > +	if (!ptr)
> >  		return NULL;
> >  
> >  	ptr++;
> >  
> >  	(*pos)++;
> >  
> > -	if (!ptr->enum_string)
> > -		return NULL;
> > +	ptr = update_enum_map(ptr);
> >  
> >  	return ptr;
> >  }
> >  



> > +	/*
> > +	 * The trace_enum_maps contains the map plus a head and tail item,
> > +	 * where the head holds the module and length of array, and the
> > +	 * tail holds a pointer to the next list.
> > +	 */
> > +	map_array = kmalloc(sizeof(*map_array) * (len + 2), GFP_KERNEL);
> >  	if (!map_array) {
> >  		pr_warning("Unable to allocate trace enum mapping\n");
> >  		return;
> >  	}
> >  
> > -	trace_enum_maps = map_array;
> > +	mutex_lock(&trace_enum_mutex);
> > +
> > +	if (!trace_enum_maps)
> > +		trace_enum_maps = map_array;
> > +	else {
> > +		ptr = trace_enum_maps;
> > +		for (;;) {
> > +			ptr = ptr + ptr->head.length + 1;
> 
> Looks like access to tail item is used frequently.  How about adding a
> helper function like enum_maps_tail_item()?

I'll look into it. Thanks for the review.

-- Steve

--
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/