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: <1069612139.6639.1453988280286.JavaMail.zimbra@efficios.com>
Date:	Thu, 28 Jan 2016 13:38:00 +0000 (UTC)
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC][BUG] tracer: Fails to work

----- On Jan 28, 2016, at 3:08 AM, Peter Zijlstra peterz@...radead.org wrote:

> Hi Steve,
> 
> So I was hunting wabbits the other day and ftrace failed to work.
> 
> After I cursed a bit on IRC, Thomas found the below, after 'fixing' it
> like so things worked enough to get the trace out.
> 
> Relying on things like this make it entirely impossible to get any trace
> data out if you've wedged a CPU. Exactly the kind of situation you want
> trace data for.
> 
> Please consider an appropriate change to make this happen.

I wonder if we should start considering using SRCU to protect
tracepoint (and other instrumentation mechanisms) critical sections
rather than RCU-sched ?

SRCU would allow us to wait for a grace-period specifically targeting
tracing, which should increase tracer robustness in face of misbehaving
CPUs. It would also allow us to do blocking calls (e.g. get_user())
from syscall entry/exit tracing, which I've been wanting to do for a
while.

Thoughts ?

Thanks,

Mathieu

> 
> ---
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 95181e36891a..b09c5b955555 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -4053,7 +4053,7 @@ EXPORT_SYMBOL_GPL(ring_buffer_read_prepare);
> void
> ring_buffer_read_prepare_sync(void)
> {
> -	synchronize_sched();
> +//	synchronize_sched();
> }
>  EXPORT_SYMBOL_GPL(ring_buffer_read_prepare_sync);

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ