Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp996127imm; Sat, 8 Sep 2018 13:29:20 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbtSLfSJ/CNnFRhR1QgAH5sQLk7G8e5blz0ZF2vkSxQUx4cPXv9WpQSA3vBWOeRLPdXosUK X-Received: by 2002:a65:464b:: with SMTP id k11-v6mr14830363pgr.448.1536438560844; Sat, 08 Sep 2018 13:29:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536438560; cv=none; d=google.com; s=arc-20160816; b=aK69wJDbAZKwSRypNW3GIEcDdgvQomlTfZ5VyMDUHTNzhzQtYuZoivktweAHyZLBrP tNekMsByisH00HWMLHe6n18SAy6LFodZKEs5qe7WngtczJ02JXQohQM1i9P+lTDujrFk li04CCrHwB7TogBjpxI80uu9OAUnJDaGSBF1Czq1Vz+35IQYTijsghAtH8Yb4g7GgOl4 6JaeGxfccN1lIr/SD2MDTtXDzQrIFk23WOuJXLmGz1ufzP8P9GRBf4hZmap7kW/Fy3B5 B7hK2OwDTiOfzwC3AP6Hfa2p9LSS2qH1c097dBnnZ4qaI0nUeb/5Rbt0Y1RRtenEXwHm yz0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dmarc-filter:dkim-signature:dkim-signature; bh=IuhyRVEQPLesG+4FUPbwTRz3OUQ+Cn6XbE7wNVAaMDQ=; b=Pz30L88oxKZUrYLsceSN39h3aEA8HLoiqy98cnBzKOteLNCdgeIyuJUhvtVLBU4EWs gI0JB63g1LxxwA7JFWpYKLqJnlht7NkrmSEH9Ey15flNOWiVEJAb8FpCspum0V0lkdyH Vzd6zsCHN8OXAiyLk2dgBuLLp4CWGBuPD+pW/XNRx5y30Y1oZAWZZ0cxce7VcjCR7JDi nOjGv1U4lfbNJpDhkZ2b7It61tPjNg3OK6EQ2g71g/1IUjWtDoVrDu5D/LJrMVft3/U7 +9f7WuxTGnF4Oh0YjB8wmR/j8bhQWC1b+ZIWCwfO2UrONP6g/LA4ZNdPDTIzKmkDVw1e R+QQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=W+14hTBO; dkim=pass header.i=@codeaurora.org header.s=default header.b=TUldIjr5; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w26-v6si12278859pgk.372.2018.09.08.13.29.00; Sat, 08 Sep 2018 13:29:20 -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=@codeaurora.org header.s=default header.b=W+14hTBO; dkim=pass header.i=@codeaurora.org header.s=default header.b=TUldIjr5; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727735AbeIIBOm (ORCPT + 99 others); Sat, 8 Sep 2018 21:14:42 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:44790 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727616AbeIIBOm (ORCPT ); Sat, 8 Sep 2018 21:14:42 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id E48286085F; Sat, 8 Sep 2018 20:27:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536438462; bh=6wg8erjEDFTQdNJQq7AYxQxvFvLfpTfESTfr62YI+Ec=; h=From:To:Cc:Subject:Date:From; b=W+14hTBOjPdBMK8ArZNBnwfXdOKKysUq9vRP95XSOtnzer5Eikx0jBRdhTWzdeQ8W wHdkUr3EOtDa2psBUYqBux/psOhmwo/8uBTKO+RlNJ/YJVkOCY66OTP5uC1A7vNgd1 kybhSOfJcMT2v8qReGvjTmzyBq+LFoRqPF3rZyaU= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from blr-ubuntu-253.qualcomm.com (blr-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.18.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan@codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id BF0A16029D; Sat, 8 Sep 2018 20:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1536438460; bh=6wg8erjEDFTQdNJQq7AYxQxvFvLfpTfESTfr62YI+Ec=; h=From:To:Cc:Subject:Date:From; b=TUldIjr5q93Osn75MmX0VLTKVNm6oBGXlNBRtVYRvw2Ok6KZFxC6aq8EWJs5F/hl2 FU8EjmnW2A9s+ZmeyNG4AmAqmrAO41TNeM05rbwJ+mbimH6p0D2REFf7C1hps0CDvL gbBmxIZTR3uR20ApU7DQZVFJs8gVjiS+kT0IFqI8= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org BF0A16029D Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=saiprakash.ranjan@codeaurora.org From: Sai Prakash Ranjan To: Steven Rostedt , Ingo Molnar , Laura Abbott , Kees Cook , Anton Vorontsov , Rob Herring , devicetree@vger.kernel.org, Colin Cross , Jason Baron , Tony Luck , Arnd Bergmann , Catalin Marinas , Will Deacon , Joel Fernandes , Masami Hiramatsu , Joe Perches , Jim Cromie Cc: Rajendra Nayak , Vivek Gautam , Sibi Sankar , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Greg Kroah-Hartman , Ingo Molnar , Tom Zanussi , Prasad Sodagudi , tsoni@codeaurora.org, Bryan Huntsman , Tingwei Zhang , Sai Prakash Ranjan Subject: [PATCH 0/6] Tracing register accesses with pstore and dynamic debug Date: Sun, 9 Sep 2018 01:57:01 +0530 Message-Id: X-Mailer: git-send-email 2.18.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, This patch series adds Event tracing support to pstore and is continuation to the RFC patch introduced to add a new tracing facility for register accesses called Register Trace Buffer(RTB). Since we decided to not introduce a separate framework to trace register accesses and use existing framework like tracepoints, I have moved from RFC. Details of the RFC in link below: Link: https://lore.kernel.org/lkml/cover.1535119710.git.saiprakash.ranjan@codeaurora.org/ MSR tracing example given by Steven was helpful in using tracepoints for register accesses instead of using separate trace. But just having these IO traces would not help much unless we could have them in some persistent ram buffer for debugging unclocked access or some kind of bus hang or an unexpected reset caused by some buggy driver which happens a lot during initial development stages. By analyzing the last few entries of this buffer, we could identify the register access which is causing the issue. But again, adding pstore support for just one such event would be unacceptable. Instead, add pstore support for all events since event tracing is widely used across the kernel to debug variety of issues and adding this support would be really useful for such purposes. In addition to this, provide dynamic debug support to filter out unwanted logs and limit trace to only specific files or directories since there can be aweful lot of register trace events and we will be interested only in specific drivers or subsystems which we will be working on. So introduce a new flag "e" to filter these event tracing to specified input. Currently only register access trace for arm64 will have this support but this could be expanded later to other events also if required. First example below shows the use of tracing events with pstore support. Here we trace sched events: # trace_event=sched tp_pstore in command line # reboot -f # mount -t pstore pstore /sys/fs/pstore/ # tail /sys/fs/pstore/event-ramoops-0 sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=rcu_preempt next_pid=10 next_prio=120 sched_switch: prev_comm=rcu_preempt prev_pid=10 prev_prio=120 prev_state=R+ ==> next_comm=swapper/1 next_pid=0 next_prio=120 sched_waking: comm=rcu_sched pid=11 prio=120 target_cpu=002 sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=002 sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=rcu_sched next_pid=11 next_prio=120 sched_switch: prev_comm=rcu_sched prev_pid=11 prev_prio=120 prev_state=R+ ==> next_comm=swapper/2 next_pid=0 next_prio=120 sched_waking: comm=reboot pid=1867 prio=120 target_cpu=000 sched_wakeup: comm=reboot pid=1867 prio=120 target_cpu=000 sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=S ==> next_comm=reboot next_pid=1867 next_prio=120 We can get more details for debugging as we can see from the above pstore output. Below is the second example for identifying the root cause of bus hang in qcom mdp tested on db410c. This hang was intentionally introduced just to show the usecase of tracing with pstore. The module used can be found here: https://github.com/saiprakash-ranjan/Bus-Hang This does an unclocked access and will reset db410c and later logs can be viewed through pstore. Here we manually specify the path to trace in kernel command line. Note: For testing purpose, I just copied bus_hang.c to drivers/soc/qcom and built it. 1) Set command line with dyndbg, trace_event and tp_pstore parameter as below: # dyndbg="file drivers/soc/qcom/* +e" trace_event=io tp_pstore 2) Bus hang by reading below debugfs entry with bus_hang module. # cat /sys/kernel/debug/hang/bus_hang 3) After restart, we can find the cause in last entry i.e. (bus_hang_mdp+0xa4/0xb8) # cat /sys/fs/pstore/event-ramoops-0 io_write: type=writel cpu=0 ts:1423426774 data=0xffff00000d5065a4 caller=qcom_smsm_probe+0x52c/0x678 io_write: type=writel cpu=0 ts:1423649847 data=0xffff00000d506608 caller=qcom_smsm_probe+0x52c/0x678 io_read: type=readl cpu=1 ts:53095994171 data=0xffff00000a51d040 caller=bus_hang_mdp+0xa4/0xb8 4) Offending register access found as below: # (gdb) # (gdb) list *(bus_hang_mdp+0xa4) # 0xffff00000867cdc8 is in bus_hang_mdp (drivers/soc/qcom/bus_hang.c:10). # 5 static int bus_hang_mdp(void *data, u64 *val) # 6 { # 7 void *p = ioremap(0x01a01000, SZ_4K); # 8 unsigned int a; # 9 # 10 a = __raw_readl((void *)((unsigned long)p + 0x40)); <---- # 11 # 12 *val = a; # 13 # 14 return 0; # (gdb) Patchwise oneline description is given below: Patch 1 adds event-size property to dt-bindings of ramoops. Patch 2 adds generic event tracing support to pstore. Patch 3 adds tp_pstore cmdline to have tracepoints go to pstore. Patch 4 adds tracepoint for register accesses, i.e. for (read/write{b,w,l,q}). Patch 5 adds new header for instrumentation of io operations. Patch 6 adds new flag for dynamic event tracing. Sai Prakash Ranjan (6): dt-bindings: ramoops: Add event-size property pstore: Add event tracing support tracing: Add tp_pstore cmdline to have tracepoints go to pstore arm64/io: Add tracepoint for register accesses arm64/io: Add header for instrumentation of io operations dynamic_debug: Add flag for dynamic event tracing .../admin-guide/kernel-parameters.txt | 21 ++++++ .../bindings/reserved-memory/ramoops.txt | 7 +- arch/arm64/include/asm/io.h | 25 +++---- arch/arm64/kernel/io.c | 22 ++++++ fs/pstore/Kconfig | 2 +- fs/pstore/ftrace.c | 55 +++++++++++++++ fs/pstore/inode.c | 4 ++ fs/pstore/ram.c | 44 +++++++++++- include/asm-generic/io-instrumented.h | 69 ++++++++++++++++++ include/asm-generic/io-trace.h | 70 +++++++++++++++++++ include/linux/dynamic_debug.h | 1 + include/linux/ftrace.h | 6 +- include/linux/pstore.h | 2 + include/linux/pstore_ram.h | 1 + kernel/sysctl.c | 7 ++ kernel/trace/Kconfig | 22 +++++- kernel/trace/trace.c | 51 ++++++++++++++ kernel/trace/trace.h | 7 ++ lib/dynamic_debug.c | 1 + 19 files changed, 393 insertions(+), 24 deletions(-) create mode 100644 include/asm-generic/io-instrumented.h create mode 100644 include/asm-generic/io-trace.h -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation