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: <20131126121026.GD27323@ghostprotocols.net>
Date:	Tue, 26 Nov 2013 09:10:26 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Stanislav Fomichev <stfomichev@...dex-team.ru>
Cc:	Chia-I Wu <olvaffe@...il.com>, a.p.zijlstra@...llo.nl,
	paulus@...ba.org, mingo@...hat.com, linux-kernel@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] perf timechart: remove lock_depth from trace_entry

Em Tue, Nov 26, 2013 at 03:05:36PM +0400, Stanislav Fomichev escreveu:
> > This makes the new tool stop processing old files, can you try the patch
> > attached instead?

> I see two downsides to your approach:

Huh?

> 1) with your patch I'm now required to run 'perf timechart record' and
> 'perf timechart' on the same machine (otherwise, on the 'perf timechart'

No, it should not be required to do that, when processing perf.data
files the tracepoint info should come from perf.data, recorded there at
the 'perf record' time, right? I'm assuming this, will check.

> machine we may have wrong fields definitions that don't match perf.data).
> Currently, it's possible to use 'perf timechart record' on the target and do
> 'perf timechart' on the host (at least I do it this way).

If it is, my assumption is correct, as the evlist must be populated from
perf.data, or is it this way and _only_ when it goes to look at fields
is that it looks at the local machine? Doesn't make sense.

> 2) only root can run 'perf timechart' now (because of permissions on
> /sys/kernel/debug).

Se above, if before this patch the format_field info was obtained from
the perf.data file, why should it now get it from the local machine?
 
> Maybe we can we make some simple version check against the perf.data file and
> just refuse to process the old one (not sure if it's possible)?
> 
> > Its only compile tested tho.
> Ok, I'll test it if we are fine with the new limitations.

Please try. There should be no limitations.

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