From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753503AbYJAOwV (ORCPT ); Wed, 1 Oct 2008 10:52:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752629AbYJAOwL (ORCPT ); Wed, 1 Oct 2008 10:52:11 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:54759 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752633AbYJAOwJ (ORCPT ); Wed, 1 Oct 2008 10:52:09 -0400 Date: Wed, 1 Oct 2008 10:52:06 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Ingo Molnar cc: Pekka Paalanen , linux-kernel@vger.kernel.org, Thomas Gleixner , Peter Zijlstra , Andrew Morton , Linus Torvalds , Mathieu Desnoyers , Frederic Weisbecker , Steven Rostedt Subject: Re: [PATCH 6/6] ftrace: take advantage of variable length entries In-Reply-To: <20081001075419.GA24509@elte.hu> Message-ID: References: <20080930030236.230994826@goodmis.org> <20080930030652.883661046@goodmis.org> <20080930203342.5b5ca814@daedalus.pq.iki.fi> <20081001075419.GA24509@elte.hu> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 Oct 2008, Ingo Molnar wrote: > > * Steven Rostedt wrote: > > > > > struct trace_entry *entry = iter->ent; > > > > - struct mmiotrace_map *m = &entry->field.mmiomap; > > > > + struct mmiotrace_map *m = (struct mmiotrace_map *)entry; > > > > > > This is different style than above, missing the struct > > > trace_mmiotrace_map intermediate step. Looks like a bug, > > > since struct mmiotrace_map is not the first field in > > > struct trace_mmiotrace_map. > > > > Crap! yes this is a bug. Thanks for pointing this out. > > hm, there's a significant amount of type casts, see the grep below. Yeah, I don't like that either. > > The ringbuffer becoming type-opaque has exactly these kinds of dangers, > and as i suggested a few days ago, please think about a debug mode that > stores the record type in the trace entry and validates it on extraction > or something like that. > > That might even be a robustness feature: the tracer should not crash if > the trace buffer gets corrupted. ftrace had that invariant before, i > think we should try to keep as many aspects of it as possible. Although the ring buffer is type opaque, that isn't the cause of this issue. Ftrace still adds the types as needed. But since we no longer have the big "one type for all" union entry, we need to be a bit more careful. All types start with a one byte type id (giving us 255 types to use for ftrace, zero being saved). The following patch fixes this bug and addresses the issue. -- Steve