Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp70637pxk; Wed, 2 Sep 2020 14:49:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxce6niLxce4Y12ouZH8P3FrmwCtO0Mx4k4GH96dA7eDQixaub4mWhlVSTXjLeZyeiWqoSw X-Received: by 2002:a17:906:4b41:: with SMTP id j1mr166810ejv.1.1599083381757; Wed, 02 Sep 2020 14:49:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599083381; cv=none; d=google.com; s=arc-20160816; b=e2WDBjlZTXzONxEa/3/juF3zqBG3+ud6IVbSE9rqTJUDxb5dD6OzYODcx8gH9MnMXU wYIud6o4QYqYDlbkdpBeYnBx+hbey+w13rEQw/mfocGoB1Y5ZTNNCHoYCahEEN8S30j8 ww1Bq8lXCl60ErlBB/8H23qbQmKaRQhFcLl3FmwX9evDcEFDZsmaCzFL+DEOsDNak6zO LDotQ+X3n/EvUHGzKvw4OOMpcjWp6bZTyQEUjSsFeOPi3XnFE/rCP8DdGj2MH4y4wZ9b 5rUq2ohBYZcvHCnOWUT1UqYkXT1c+9eQctaACwvpxDxah0X1fcJWjyKMgGYTRsCNyfT8 gusA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Xily/0xvJGstnoyA+d4M7lfqBwEiG+KuuEoHjuwJurQ=; b=xRZ0qHH4gqwibIkCN5Mo2FAAj5BUfW3jsogDF5OszKLNHQCDMoO+PtMgJ+cIB3rG7x t31IQe4LR+hJnEJA17TYxQCYmxVNDA1DgqY19BWoczHjQv8GaujJdPPPVhjBuoQ0/mde /B1sxvEoE5h6/KvoqcsCitGzoHVhuRfVKayKLw0jNs1WJ7CZWJWIBE/n0O5wP7Zm0OUZ a4tRqcSpFK3JbSsdDkkG4z/xcFQHhrT2nqwsYVXW/oHd1suKYnJLSASdqvyiqaytl0da vKxlKRWstIfmI02zZ+dZunVJZJIBpltDEYtQfiu0c849Ebzc2IhQbZOm55+suhmkrnWd po4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=djNZsNkc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t7si351212edt.107.2020.09.02.14.49.19; Wed, 02 Sep 2020 14:49:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=djNZsNkc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726928AbgIBVsA (ORCPT + 99 others); Wed, 2 Sep 2020 17:48:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726226AbgIBVr7 (ORCPT ); Wed, 2 Sep 2020 17:47:59 -0400 Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17D09C061244 for ; Wed, 2 Sep 2020 14:47:59 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id g13so508113ioo.9 for ; Wed, 02 Sep 2020 14:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Xily/0xvJGstnoyA+d4M7lfqBwEiG+KuuEoHjuwJurQ=; b=djNZsNkcJEUqSMyXoGRoGMbecvhRQg7H6wFV0CGohP7g3I0JzmlxO/zspibZuAoEIY zErSvTEBqP/ytOvJf4PsfEddQTzx7u1lyk00ycRPE5myKyJ5GKJecPJWCGZz6NOHx/Mw 6Anit2n407iyA9SdzdNEDjFMNUdMft36P78pM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Xily/0xvJGstnoyA+d4M7lfqBwEiG+KuuEoHjuwJurQ=; b=KVgdl3u1FNaTNFwixuVrQIVRQpGflqaA/wC1VlPwDiY2RVI0IgqzOX/yz+BltgAtTJ TeRgIvENrpuf54LUJCtSGsNtvI7oOdzgGm9nHANFG3RdUJ81kJTvL6wkWKS93VSsSyxB nyW9fhxnBURLJXRwL7y7Dbn3tGQqEpB4Vp7UvFGwCpwyJ3/MkzLGPYmQlN37DUMdFQ+A acbUhTiQbT7zjIVRD5UgWc+gaYnmt8MPYijieXXFDqGovXIm5q0m6xMA1vwhjLLc8NLD 5y+j5uRa9p9d8Cv0Pdwh/h+IKYVkiLwRmM0Qcnle2CKrKkMQlMEJfrLDm3EW+0DchQnO pGGA== X-Gm-Message-State: AOAM532ZprGc1Te4To2SfJchXMcpiiQNFEzTw8rjGSdBS6XC1BxZlLvd hEVauhHYdUNd9DIFqirY6do4ooxRxpyeIakKL3VyJQ== X-Received: by 2002:a05:6638:24d1:: with SMTP id y17mr102793jat.42.1599083278337; Wed, 02 Sep 2020 14:47:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joel Fernandes Date: Wed, 2 Sep 2020 17:47:44 -0400 Message-ID: Subject: Re: [RFC PATCH 0/7] Trace events to pstore To: Nachammai Karuppiah Cc: Steven Rostedt , Ingo Molnar , Rob Herring , Frank Rowand , Kees Cook , Anton Vorontsov , Colin Cross , Tony Luck , LKML , Sai Prakash Ranjan , computersforpeace@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 2, 2020 at 4:01 PM Nachammai Karuppiah wrote: > > Hi, > > This patch series adds support to store trace events in pstore. > > Storing trace entries in persistent RAM would help in understanding what > happened just before the system went down. The trace events that led to t= he > crash can be retrieved from the pstore after a warm reboot. This will hel= p > debug what happened before machine=E2=80=99s last breath. This has to be = done in a > scalable way so that tracing a live system does not impact the performanc= e > of the system. Just to add, Nachammai was my intern in the recent outreachy program and we designed together a way for trace events to be written to pstore backed memory directory instead of regular memory. The basic idea is to allocate frace's ring buffer on pstore memory and have it right there. Then recover it on reboot. Nachammai wrote the code with some guidance :) . I talked to Steve as well in the past about the basic of idea of this. Steve is on vacation this week though. This is similar to what +Sai Prakash Ranjan was trying to do sometime ago: https://lkml.org/lkml/2018/9/8/221 . But that approach involved higher overhead due to synchronization of writing to the otherwise lockless ring buffer. +Brian Norris has also expressed interest for this feature. thanks, - Joel > > This requires a new backend - ramtrace that allocates pages from > persistent storage for the tracing utility. This feature can be enabled > using TRACE_EVENTS_TO_PSTORE. > In this feature, the new backend is used only as a page allocator and > once the users chooses to use pstore to record trace entries, the ring > buffer pages are freed and allocated in pstore. Once this switch is done, > ring_buffer continues to operate just as before without much overhead. > Since the ring buffer uses the persistent RAM buffer directly to record > trace entries, all tracers would also persist across reboot. > > To test this feature, I used a simple module that would call panic during > a write operation to file in tracefs directory. Before writing to the fil= e, > the ring buffer is moved to persistent RAM buffer through command line > as shown below, > > $echo 1 > /sys/kernel/tracing/options/persist > > Writing to the file, > $echo 1 > /sys/kernel/tracing/crash/panic_on_write > > The above write operation results in system crash. After reboot, once the > pstore is mounted, the trace entries from previous boot are available in = file, > /sys/fs/pstore/trace-ramtrace-0 > > Looking through this file, gives us the stack trace that led to the crash= . > > <...>-1 [001] .... 49.083909: __vfs_write <-vfs_write > <...>-1 [001] .... 49.083933: panic <-panic_on_write > <...>-1 [001] d... 49.084195: printk <-panic > <...>-1 [001] d... 49.084201: vprintk_func <-printk > <...>-1 [001] d... 49.084207: vprintk_default <-printk > <...>-1 [001] d... 49.084211: vprintk_emit <-printk > <...>-1 [001] d... 49.084216: __printk_safe_enter <-vpr= intk_emit > <...>-1 [001] d... 49.084219: _raw_spin_lock <-vprintk_= emit > <...>-1 [001] d... 49.084223: vprintk_store <-vprintk_e= mit > > Patchwise oneline description is given below: > > Patch 1 adds support to allocate ring buffer pages from persistent RAM bu= ffer. > > Patch 2 introduces a new backend, ramtrace. > > Patch 3 adds methods to read previous boot pages from pstore. > > Patch 4 adds the functionality to allocate page-sized memory from pstore. > > Patch 5 adds the seq_operation methods to iterate through trace entries. > > Patch 6 modifies ring_buffer to allocate from ramtrace when pstore is use= d. > > Patch 7 adds ramtrace DT node as child-node of /reserved-memory. > > Nachammai Karuppiah (7): > tracing: Add support to allocate pages from persistent memory > pstore: Support a new backend, ramtrace > pstore: Read and iterate through trace entries in PSTORE > pstore: Allocate and free page-sized memory in persistent RAM buffer > tracing: Add support to iterate through pages retrieved from pstore > tracing: Use ramtrace alloc and free methods while using persistent > RAM > dt-bindings: ramtrace: Add ramtrace DT node > > .../bindings/reserved-memory/ramtrace.txt | 13 + > drivers/of/platform.c | 1 + > fs/pstore/Makefile | 2 + > fs/pstore/inode.c | 46 +- > fs/pstore/platform.c | 1 + > fs/pstore/ramtrace.c | 821 +++++++++++++++= ++++++ > include/linux/pstore.h | 3 + > include/linux/ramtrace.h | 28 + > include/linux/ring_buffer.h | 19 + > include/linux/trace.h | 13 + > kernel/trace/Kconfig | 10 + > kernel/trace/ring_buffer.c | 663 +++++++++++++++= +- > kernel/trace/trace.c | 312 +++++++- > kernel/trace/trace.h | 5 +- > 14 files changed, 1924 insertions(+), 13 deletions(-) > create mode 100644 Documentation/devicetree/bindings/reserved-memory/ram= trace.txt > create mode 100644 fs/pstore/ramtrace.c > create mode 100644 include/linux/ramtrace.h > > -- > 2.7.4 >