From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7BA87C433E5 for ; Thu, 23 Jul 2020 21:44:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 55D342080D for ; Thu, 23 Jul 2020 21:44:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="uDfZmcKs"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="gtKjIi1m" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727781AbgGWVo1 (ORCPT ); Thu, 23 Jul 2020 17:44:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60442 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbgGWVo0 (ORCPT ); Thu, 23 Jul 2020 17:44:26 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93BCEC0619D3; Thu, 23 Jul 2020 14:44:26 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1595540664; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YJAOZn+NV3c8JWx5UIem9HzDm7TCzzCZdh+QLWV9zos=; b=uDfZmcKsPrtAZ9EPCn7wuQ2LYhtSESV/A3K5F2BxInsEbE5KGH3iTpU6hfb8Iq3xSCK73q V9Cj62JEzbOFW3OO9Qd4MRy2gZ2LSAw0z46WszgaNU/zJbi7ZP7wk8dnXiKQf60M7aLhsx jA/7O0lW2KwCga8BN95btUdT1LJ9rQgh/X0cFNLnGiatFNKk6B3MMAUoyAmKRGq5mWhl79 odbPA/3HPG1ndaQplTcsZgUZws6tgJxUTJ71z6h374VhakEAxq6k5LLugh0TyHZ/kGjtDo JwM8uW6KKdYjq7gj0dY71e+o+dj1Dtmc74+ETE3waVxSWFBvllqwwCzBYnJN7g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1595540664; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YJAOZn+NV3c8JWx5UIem9HzDm7TCzzCZdh+QLWV9zos=; b=gtKjIi1mnr4FAzRJ1lQR9YtI+U6Z6fGDmO5VwPoawB9wYFUsAn5WivGjVh4rSWoYiyjTpS sAHmg2otDHvRriBw== To: Alex Belits , "peterz\@infradead.org" Cc: "davem\@davemloft.net" , Prasun Kapoor , "mingo\@kernel.org" , "linux-api\@vger.kernel.org" , "rostedt\@goodmis.org" , "frederic\@kernel.org" , "catalin.marinas\@arm.com" , "linux-arch\@vger.kernel.org" , "will\@kernel.org" , "linux-kernel\@vger.kernel.org" , "netdev\@vger.kernel.org" , "linux-arm-kernel\@lists.infradead.org" Subject: Re: [PATCH v4 00/13] "Task_isolation" mode In-Reply-To: <3ff1383e669b543462737b0d12c0d1fb7d409e3e.camel@marvell.com> References: <04be044c1bcd76b7438b7563edc35383417f12c8.camel@marvell.com> <87imeextf3.fsf@nanos.tec.linutronix.de> <831e023422aa0e4cb3da37ceef6fdcd5bc854682.camel@marvell.com> <20200723154933.GB709@worktop.programming.kicks-ass.net> <3ff1383e669b543462737b0d12c0d1fb7d409e3e.camel@marvell.com> Date: Thu, 23 Jul 2020 23:44:24 +0200 Message-ID: <877dutx5xj.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alex Belits writes: > On Thu, 2020-07-23 at 17:49 +0200, Peter Zijlstra wrote: >> >> 'What does noinstr mean? and why do we have it" -- don't dare touch >> the >> entry code until you can answer that. > > noinstr disables instrumentation, so there would not be calls and > dependencies on other parts of the kernel when it's not yet safe to > call them. Relevant functions already have it, and I add an inline call > to perform flags update and synchronization. Unless something else is > involved, those operations are safe, so I am not adding anything that > can break those. Sure. 1) That inline function can be put out of line by the compiler and placed into the regular text section which makes it subject to instrumentation 2) That inline function invokes local_irq_save() which is subject to instrumentation _before_ the entry state for the instrumentation mechanisms is established. 3) That inline function invokes sync_core() before important state has been established, which is especially interesting in NMI like exceptions. As you clearly documented why all of the above is safe and does not cause any problems, it's just me and Peter being silly, right? Try again. Thanks, tglx