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:	Tue, 16 Feb 2016 10:01:21 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Denis Kirjanov <kda@...ux-powerpc.org>
Cc:	linux-kernel@...r.kernel.org, paulmck@...ux.vnet.ibm.com
Subject: Re: [PATCH 1/2] tracing/mm: don't trace kfree on offline CPUs

On Tue, 16 Feb 2016 08:52:24 +0300
Denis Kirjanov <kda@...ux-powerpc.org> wrote:

> On 2/15/16, Steven Rostedt <rostedt@...dmis.org> wrote:
> > On Sun, 14 Feb 2016 23:19:42 +0300
> > Denis Kirjanov <kda@...ux-powerpc.org> wrote:
> >
> >  
> >> >>  	TP_PROTO(unsigned long call_site, const void *ptr),
> >> >>
> >> >> -	TP_ARGS(call_site, ptr)
> >> >> +	TP_ARGS(call_site, ptr),
> >> >> +
> >> >> +	/*
> >> >> +	 * This trace can be potentially called from an offlined cpu.
> >> >> +	 * Since trace points use RCU and RCU should not be used from
> >> >> +	 * offline cpus, filter such calls out.
> >> >> +	 * While this trace can be called from a preemptable section,
> >> >> +	 * it has no impact on the condition since tasks can migrate
> >> >> +	 * only from online cpus to other online cpus. Thus its safe
> >> >> +	 * to use raw_smp_processor_id.
> >> >> +	 */
> >> >> +	TP_CONDITION(cpu_online(raw_smp_processor_id()))  
> >> >
> >> > This is starting to become a common occurrence. Perhaps it is best to
> >> > just hardcode this into the tracepoint code itself?  
> >>
> >> Can you take it as a fix for now. I'll post the follow-up patch then
> >> for rcu and offline cpus
> >> issue.  
> >
> > Actually, I prefer not to add more checks for cpu_online(), if its
> > going to become the default.
> >
> > Does this work for you instead?  
> 
> Hm, somehow it doesn't work:

But your patch works? Strange, because my exit condition is done before
the conditional part of the trace event. Thus, if this didn't work,
than your original patch should not work either.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ