From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752415AbbCSWlz (ORCPT ); Thu, 19 Mar 2015 18:41:55 -0400 Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.230]:31276 "EHLO cdptpa-oedge-vip.email.rr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752281AbbCSWlZ (ORCPT ); Thu, 19 Mar 2015 18:41:25 -0400 Date: Thu, 19 Mar 2015 18:42:13 -0400 From: Steven Rostedt To: Linus Torvalds Cc: LKML , Ingo Molnar , Andrew Morton , stable , Christoph Lameter , Uwe Kleine-Koenig Subject: Re: [GIT PULL] ring-buffer: Replace this_cpu_*() with __this_cpu_*() Message-ID: <20150319184213.54e8bb16@grimm.local.home> In-Reply-To: <20150319183444.3d26f078@grimm.local.home> References: <20150319180216.62c9fa4a@gandalf.local.home> <20150319183444.3d26f078@grimm.local.home> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Mar 2015 18:34:44 -0400 Steven Rostedt wrote: > On Thu, 19 Mar 2015 15:16:25 -0700 > Linus Torvalds wrote: > > > So I don't think the ring-buffer change is necessarily _wrong_, but if > > this is a performance issue, why don't we just fix it up for the > > generic case rather than for just one user? > > I totally agree with your analysis, but it's up to Christoph to come up > with an answer to your questions. > I will add that the ring buffer issue is not just a performance problem. It is a correctness problem. The generic preempt_disable/enable() functions can be traced by the function tracer, where as the preempt_disable/enable_notrace() versions are not. As tracing is very invasive, and can cause unnecessary recursions, there are protection mechanisms to prevent something like that happening. The issue that this patch addresses is that the recursion protection is the code that happens to be causing the recursion! some_function() function_tracer() ring_buffer_reserve() trace_recursive_lock() this_cpu_read() preempt_disable() function_tracer() ring_buffer_reserve() trace_recursion_lock() (etc) The reason this did not happen is that the function_tracer() also has its own recursion protection that uses current->trace_recursion to prevent that from happening. But if there was some function tracing that did not check recursion and calls into the ring buffer, that could crash the system. -- Steve