Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755598AbaG3RX7 (ORCPT ); Wed, 30 Jul 2014 13:23:59 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:49848 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755302AbaG3RX4 (ORCPT ); Wed, 30 Jul 2014 13:23:56 -0400 MIME-Version: 1.0 In-Reply-To: <20140730164344.GA27954@localhost.localdomain> References: <7123b2489cc5d1d5abb7bcf1364ca729cab3e6ca.1406604806.git.luto@amacapital.net> <20140729193232.GA8153@redhat.com> <20140730164344.GA27954@localhost.localdomain> From: Andy Lutomirski Date: Wed, 30 Jul 2014 10:23:34 -0700 Message-ID: Subject: Re: [PATCH v4 2/5] x86,entry: Only call user_exit if TIF_NOHZ To: Frederic Weisbecker Cc: Oleg Nesterov , "linux-kernel@vger.kernel.org" , Kees Cook , Will Drewry , X86 ML , "linux-arm-kernel@lists.infradead.org" , Linux MIPS Mailing List , linux-arch , LSM List , Alexei Starovoitov , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 30, 2014 at 9:43 AM, Frederic Weisbecker wrote: > On Tue, Jul 29, 2014 at 09:32:32PM +0200, Oleg Nesterov wrote: >> On 07/28, Andy Lutomirski wrote: >> > >> > @@ -1449,7 +1449,12 @@ long syscall_trace_enter(struct pt_regs *regs) >> > { >> > long ret = 0; >> > >> > - user_exit(); >> > + /* >> > + * If TIF_NOHZ is set, we are required to call user_exit() before >> > + * doing anything that could touch RCU. >> > + */ >> > + if (test_thread_flag(TIF_NOHZ)) >> > + user_exit(); >> >> Personally I still think this change just adds more confusion, but I leave >> this to you and Frederic. >> >> It is not that "If TIF_NOHZ is set, we are required to call user_exit()", we >> need to call user_exit() just because we enter the kernel. TIF_NOHZ is just >> the implementation detail which triggers this slow path. >> >> At least it should be correct, unless I am confused even more than I think. > > Agreed, Perhaps the confusion is on the syscall_trace_enter() name which suggests > this is only about tracing? syscall_slowpath_enter() could be an alternative. > But that's still tracing in a general sense so... At the end of the day, the syscall slowpath code calls a bunch of functions depending on what TIF_XYZ flags are set. As long as it's structured like "if (TIF_A) do_a(); if (TIF_B) do_b();" or something like that, it's comprehensible. But once random functions with no explicit flag checks or comments start showing up, it gets confusing. If it's indeed all-or-nothing, I could remove the check and add a comment. But please keep in mind that, currently, the slow path is *slow*, and my patches only improve the entry case. So enabling context tracking on every task will hurt. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/