linux-kernel - Re: [PATCH 6/6] perf tools: Bring linear set of section headers for features

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] [day] [month] [year] [list]

Message-ID: <20091111173228.GB27237@ghostprotocols.net>
Date:	Wed, 11 Nov 2009 15:32:28 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Subject: Re: [PATCH 6/6] perf tools: Bring linear set of section headers
	for features

Em Wed, Nov 11, 2009 at 05:49:37PM +0100, Frederic Weisbecker escreveu:
> On Wed, Nov 11, 2009 at 07:20:04AM +0100, Peter Zijlstra wrote:
> > On Wed, 2009-11-11 at 04:51 +0100, Frederic Weisbecker wrote:
> > > Build a set of section headers for features right after the datas.
> > > Each implemented feature will have one of such section header that
> > > provides the offset and the size of the data manipulated by the feature.
> > > 
> > > The trace informations have moved after the data and are recorded
> > > on exit time.
> > > 
> > > The new layout is as follows:
> > > 
> > >  -----------------------
> > >                              ___
> > >  [ magic               ]      |
> > >  [ header size         ]      |
> > >  [ attr size           ]      |
> > >  [ attr content offset ]      |
> > >  [ attr content size   ]      |
> > >  [ data offset         ]  File Headers
> > >  [ data size           ]      |
> > >  [ event_types offset  ]      |
> > >  [ event_types size    ]      |
> > >  [ feature bitmap      ]      v 
> > > 
> > >  [ attr section        ]
> > >  [ events section      ]
> > > 
> > >                              ___
> > >  [         X           ]      |
> > >  [         X           ]      |
> > >  [         X           ]    Datas
> > >  [         X           ]      |
> > >  [         X           ]      v
> > > 
> > >                              ___
> > >  [ Feature 1 offset    ]      |
> > >  [ Feature 1 size      ] Features headers
> > >  [ Feature 2 offset    ]      |
> > >  [ Feature 2 size      ]      v
> > > 
> > >  [ Feature 1 content   ]
> > >  [ Feature 2 content   ]
> > >  -----------------------
> > > 
> > > We have as many feature's section headers as we have features in use for
> > > the current file.
> > > 
> > > Say Feat 1 and Feat 3 are used by the file, but not Feat 2. Then the
> > > feature headers will be like follows:
> > > 
> > > [ Feature 1 offset    ]      |
> > > [ Feature 1 size      ] Features headers
> > > [ Feature 3 offset    ]      |
> > > [ Feature 3 size      ]      v
> > > 
> > > There is no hole to cover Feature 2 that is not in use here. We only
> > > need to cover the needed headers in order, from the lowest feature bit
> > > to the highest.
> > > 
> > > Currently we have two features: HEADER_TRACE_INFO and HEADER_BUILD_ID.
> > > Both have their contents that follow the feature headers. Putting the
> > > contents right after the feature headers is not mandatory though.
> > > While we keep the feature headers right after the data and in order,
> > > their offsets can point everywhere. We have just put the two above
> > > feature contents in the end of the file for convenience.
> > > 
> > > The purpose of this layout change is to have a file format that scales
> > > while keeping it simple: having such linear feature headers is less
> > > error prone wrt forward/backward compatibility as the content of a
> > > feature can be put anywhere, its location can even change by the
> > > time, it's fine because its headers will tell where it is. And we know
> > > how to find these headers, following the above rules.
> > 
> > Does do mess up append though... be sure to add some magic for that.
> 
> Yep. It seems to work. What happens is that trace information are
> re-computed. The same goes for build id I guess.

Well, we would need to get the existing buildids, insert them into the
dsos list, and as we use dsos__findnew DSOs already in the list wouldn't
be added, and at the end we would, as you say, recompute the buildid
table.
 
> What happens is that the appended datas override the features sections
> and headers, but this is fine because we rewrite them in the end.
> 
> But these both need to support appending mode internally (ie: append
> the new informtions on top of exisiting ones instead of redo the whole)
> and then rewrite the whole at exit like it's done currently.

yeah.

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