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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 5 Dec 2011 11:24:05 -0800
From:	Stephane Eranian <eranian@...gle.com>
To:	Robert Richter <robert.richter@....com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	"acme@...hat.com" <acme@...stprotocols.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"dsahern@...il.com" <dsahern@...il.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [PATCH] perf: make perf.data more self-descriptive (v8)

On Mon, Dec 5, 2011 at 5:23 AM, Robert Richter <robert.richter@....com> wrote:
> On 01.12.11 09:53:10, Stephane Eranian wrote:
>> On Thu, Dec 1, 2011 at 7:15 AM, Robert Richter <robert.richter@....com> wrote:
>> > I am asking this because I want to change code in a way that treats
>> > all features the same, that is just to disable the feature bit on
>> > failure and then continue anyway.
>> >
>> You need to make sure that disabling the bit is enough to still get a consistent
>> file, i.e., want to undo the effect of writing the feature to the
>> file. In the case
>> of the meta-data features I added that was easy simply lseek() back to
>> the position
>> before the call. Would that be the case with TRACE_INFO?
>
> It should be. All features can be parsed independently. Offset and
> size of a feature's data block is stored in struct perf_file_section
> right after the data block of perf.data (see perf_session__write_
> header()). Thus, if a feature does not exist then other features can
> be processed anyway.
>
The one thing I realized last week, is that all that header information, incl.
the features bits do not seem to appear in the file perf.data file when you
use the perf record pipe mode. We need to fix that otherwise, if you
depend on information in those bits, it won't always be present. That's
a major issue.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ