[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54D3186F.7030500@sr71.net>
Date: Wed, 04 Feb 2015 23:14:55 -0800
From: Dave Hansen <dave@...1.net>
To: sedat.dilek@...il.com, Paul McKenney <paulmck@...ux.vnet.ibm.com>
CC: "Rafael J. Wysocki" <rjw@...ysocki.net>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
linux-next <linux-next@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Kristen Carlson Accardi <kristen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: linux-next: Tree for Feb 4
On 02/04/2015 05:53 PM, Sedat Dilek wrote:
> The architecture-specific switch_mm() function can be called by offline
> CPUs, but includes event tracing, which cannot be legally carried out
> on offline CPUs. This results in a lockdep-RCU splat. This commit fixes
> this splat by omitting the tracing when the CPU is offline.
...
>>> >> > load_cr3(next->pgd);
>>> >> > - trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL);
>>> >> > + if (cpu_online(smp_processor_id()))
>>> >> > + trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL);
Is this, perhaps, something that we should be doing in the generic trace
code so that all of the trace users don't have to worry about it? Also,
this patch will add overhead to the code when tracing is off. It would
be best if we could manage to make the cpu_online() check only in the
cases where the tracepoint is on.
--
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