Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp661779yba; Wed, 3 Apr 2019 17:02:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqyzGphPwa2wMsKTT5fdeyvTmKc8fviByIF5xySyoJ6VlN6zL6F4XrbqGdsac+TkSz7VJslP X-Received: by 2002:a17:902:765:: with SMTP id 92mr2889451pli.95.1554336135340; Wed, 03 Apr 2019 17:02:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554336135; cv=none; d=google.com; s=arc-20160816; b=C0HmO7QJNtpYTSsL/BwKWG7rr7M4eFOPQBVUNXvHZkwquK2LibMwMkb4CuCoQYKksG 0p7cXXwHegBo8NMwxiLVCNAyZLMKlaphhxIZlXrGmOXyzWzjaM8KUrEh9mkL1sZy9lln h4OmL1h9V2TGfg+0FvTMWOlEnIRs92FYH5djkOW9rautQAd1GwOWpcFzvTAdddIzhn7Y 9/pOeY5SA35DwQ3d6/011yDYCL2l6c38kbDArmdyWaNLbfSPNA1jIQ56+sInGWD5mXzI z98Y7qRcOHqzInkHYiuJYSFJ/hxkNOFBJuExtW1VTrn1ieEFU3+BhQuMvLAJFnraMRG1 +2ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Hrep/lQsCG6hApZu9z+Pqjy2WsPKBSyzf1ACCQuu2y8=; b=fjqeMN8LT+R6ai9vl5qZ9zIrAtRNb3CxcAenuwX73wj2OSKGRiQSFzJohD72YvLbn6 RFx8EkYrXhmIg+ZlHpzanjkwV2fh++uM6/7yzIbE9gEU4kh6ZT5SW8/D+XeQ5yldRbHO KAeGhJGSSOt+YNw3MpRVXsBQ42Y6CM2NShs1sd4DYGDdeNnxNU2bpYjOu6cOZUwRtUqO 5XsrB/fMkRmRjfsbNC0qp4Rb4gTHgODQe4odtw3HHMBducDuBcJDusyOy6qIhXprMQFH mOnFOiRbl1Hc9ZSEnRd05IkRD1mv7tghQqQyql6Gg9x4XzNCiIkbNrFdkOEnV1flcHuI 4LRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=xHIxqd2g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k22si6761075pfo.145.2019.04.03.17.01.59; Wed, 03 Apr 2019 17:02:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=xHIxqd2g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726415AbfDDABS (ORCPT + 99 others); Wed, 3 Apr 2019 20:01:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:34250 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726167AbfDDABR (ORCPT ); Wed, 3 Apr 2019 20:01:17 -0400 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 261B4217D7 for ; Thu, 4 Apr 2019 00:01:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554336076; bh=ZPX475rPsm+JcsUyCA+9ooqeKYzOEmOziLymNX1DeUY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=xHIxqd2gVYkBgGYcWilTWX4CLXHkENLc0Kx3g5CMt0pjeINfBB4/DHHCH/naeBGvX e++4o8xEsYUO5Q7UfsWRBIQE/YtGtTNgD7W2WBqixbRwK8m9fDN0ydTLBYg0fYDWKN 0AtTH/ONyO/mOyc7QJrU3pUnDBCxPSTs+Ad947+g= Received: by mail-wr1-f54.google.com with SMTP id q1so1157408wrp.0 for ; Wed, 03 Apr 2019 17:01:16 -0700 (PDT) X-Gm-Message-State: APjAAAVGne98nleiqWwcSAe0VXhBFekuF2iGVYIMsUqONvfrK2zPrd9A JjUCMgdPsjR5V0+5QIiBVg7qVsBvQEExAmrqpXjlHQ== X-Received: by 2002:adf:fd46:: with SMTP id h6mr1598988wrs.139.1554336074602; Wed, 03 Apr 2019 17:01:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Wed, 3 Apr 2019 17:01:02 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/7] Early task context tracking To: Daniel Bristot de Oliveira Cc: LKML , Steven Rostedt , Arnaldo Carvalho de Melo , Ingo Molnar , Andy Lutomirski , Thomas Gleixner , Borislav Petkov , Peter Zijlstra , "H. Peter Anvin" , "Joel Fernandes (Google)" , Jiri Olsa , Namhyung Kim , Alexander Shishkin , Tommaso Cucinotta , Romulo Silva de Oliveira , Clark Williams , X86 ML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Apr 2, 2019, at 2:03 PM, Daniel Bristot de Oliveira wrote: > > Note: do not take it too seriously, it is just a proof of concept. > > Some time ago, while using perf to check the automaton model, I noticed > that perf was losing events. The same was reproducible with ftrace. > > See: https://www.spinics.net/lists/linux-rt-users/msg19781.html > > Steve pointed to a problem in the identification of the context > execution used by the recursion control. > > Currently, recursion control uses the preempt_counter to > identify the current context. The NMI/HARD/SOFT IRQ counters > are set in the preempt_counter in the irq_enter/exit functions. > > In a trace, they are set like this: > -------------- %< -------------------- > 0) ==========> | > 0) | do_IRQ() { /* First C function */ > 0) | irq_enter() { > 0) | /* set the IRQ context. */ > 0) 1.081 us | } > 0) | handle_irq() { > 0) | /* IRQ handling code */ > 0) + 10.290 us | } > 0) | irq_exit() { > 0) | /* unset the IRQ context. */ > 0) 6.657 us | } > 0) + 18.995 us | } > 0) <========== | > -------------- >% -------------------- > > As one can see, functions (and events) that take place before the set > and after unset the preempt_counter are identified in the wrong context, > causing the miss interpretation that a recursion is taking place. > When this happens, events are dropped. > > To resolve this problem, the set/unset of the IRQ/NMI context needs to > be done before the execution of the first C execution, and after its > return. By doing so, and using this method to identify the context in the > trace recursion protection, no more events are lost. I would much rather do the opposite: completely remove context tracking from the asm and, instead, stick it into the C code. We'd need to make sure that the C code is totally immune from tracing, kprobes, etc, but it would be a nice cleanup. And then you could fix this bug in C! > > A possible solution is to use a per-cpu variable set and unset in the > entry point of NMI/IRQs, before calling the C handler. This possible > solution is presented in the next patches as a proof of concept, for > x86_64. However, other ideas might be better than mine... so... > > Daniel Bristot de Oliveira (7): > x86/entry: Add support for early task context tracking > trace: Move the trace recursion context enum to trace.h and reuse it > trace: Optimize trace_get_context_bit() > trace/ring_buffer: Use trace_get_context_bit() > trace: Use early task context tracking if available > events: Create an trace_get_context_bit() > events: Use early task context tracking if available > > arch/x86/entry/entry_64.S | 9 ++++++ > arch/x86/include/asm/irqflags.h | 30 ++++++++++++++++++++ > arch/x86/kernel/cpu/common.c | 4 +++ > include/linux/irqflags.h | 4 +++ > kernel/events/internal.h | 50 +++++++++++++++++++++++++++------ > kernel/softirq.c | 5 +++- > kernel/trace/ring_buffer.c | 28 ++---------------- > kernel/trace/trace.h | 46 ++++++++++++++++++++++-------- > 8 files changed, 129 insertions(+), 47 deletions(-) > > -- > 2.20.1 >