linux-kernel - Re: [PATCH 0/3] ARM Coresight: Enhance ETM tracing control

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:	Wed, 4 Dec 2013 15:02:39 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Adrien Vergé <adrienverge@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Will Deacon <will.deacon@....com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH 0/3] ARM Coresight: Enhance ETM tracing control

On Wed, Dec 04, 2013 at 04:12:56PM -0500, Adrien Vergé wrote:
> 2013/12/4 Greg Kroah-Hartman <gregkh@...uxfoundation.org>:
> > Your pid implementation is broken, see my other email about that :(
> 
> Thank you for your remarks on pid. I'll try to correct that.
> 
> > And again, what's wrong with the existing tracing functionalty that is
> > processor agnostic?  Why can't we just delete this driver today and use
> > the existing trace code?
> 
> As far as I know, the tracing functionality in
> /sys/kernel/debug/tracing does not take advantage of ETM. ETM is a
> dedicated hardware that greatly reduces tracing overhead. It only
> exists on ARM platforms.

How much overhead does the existing tracing code have on ARM?  Is ETM
still even needed?  Why not just use ETM for the core tracing code
instead?

> I understand using sysfs here is not the cleanest way. I patched my
> kernel to meet my needs (trace a specific process or address range),
> and I thought these small modifications could be useful -- until
> bigger work is done to remove ETM control from sysfs.
> 
> Do you think it's worth correcting my patch (for pid namespaces) and
> re-submitting it? Or should we wait for someone to port ETM tracing to
> debugfs?

What's wrong with the in-kernel tracing logic that you can't use that
instead of the ETM stuff?

And no, I don't think adding more functionality to this will be good to
do, ideally it could just be dropped...

thanks,

greg k-h
--
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/