Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp818180img; Wed, 20 Mar 2019 11:30:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqy3TygDaX7gsDj2Af293b3+DsZL9IJhAbCtMxMajEGu/v/d+ooOPS/qkCQJbT1/4cT7sD4z X-Received: by 2002:a17:902:20eb:: with SMTP id v40mr9880131plg.20.1553106635008; Wed, 20 Mar 2019 11:30:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553106634; cv=none; d=google.com; s=arc-20160816; b=Ah4kafWgdPXdMm+QKgKTAl35wL0u4dZF6baV5MbhZb4sWqQhT21KQrrrJgap7yJxjN fu3j/9mr5ESKZTivxSmPeN6N28lKq+66GA7qwkzlObF1i6fMvIGWwYSOj0TgRnZlrwry 3MBF7yVaKSrMHtV3TJQxKGy7PTKsXfxlvzVZ14zoIkdvE6b3yhvi/aHJjMl9UTTw2+dK TO/woJ0sl5+MJlvdHr3atyfdwNSygWqU8Sk9W2GL2ffklS7OOIJ41K7TbDseb4X9yE0A b94znGe8UErC4J2RSnXx1nbJzNlxa1wJjiiVu6CnQ53qI4y/RLlrx0WWXJcZtdl+XgTj KByg== 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:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=SwH/l6jXqNIZfIo7XbroF1D9grWvrl3h19wwI04COw0=; b=L3M+PNPT8F4ppg/qrnC4vtpzTth8Fnl7Zb+kZRPpD+GNSDuNfq8KML/Zdi6Bp0Me18 SXLmRKfMyiR756dBvhhO/3MWQPda1J6y0Qfs3DKsJ/l3EEjjq0ApUaZLbvGHvhLJHaRG muHmvXcHRHgmfq3I2AMqo8H4Zw2DYPj3Z+AxXknA4VEqjI7wqN5EEuMPM6uOxAkZYsIc 0k70qC2ceZUfeUfbHBezyRBuAGlBmhn/ll6hm/YjzJPsHtuXdu3ACpuo7UNEfXvkALqG DAfw0yJReVz4z9hhmEBi2v1a2F20WkTXk1yw1nrMXh/PoyBG5Vt4hS8puC7kPuzKj13a cjfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b="qbW/+GhR"; 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=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4si2133269pgv.118.2019.03.20.11.30.19; Wed, 20 Mar 2019 11:30:34 -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=@oracle.com header.s=corp-2018-07-02 header.b="qbW/+GhR"; 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=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727494AbfCTS3l (ORCPT + 99 others); Wed, 20 Mar 2019 14:29:41 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:57550 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727162AbfCTS3k (ORCPT ); Wed, 20 Mar 2019 14:29:40 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2KISwaR066807; Wed, 20 Mar 2019 18:29:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=SwH/l6jXqNIZfIo7XbroF1D9grWvrl3h19wwI04COw0=; b=qbW/+GhRNqc8dOdYJqL/mP9JERS0hrweZNqdNbwIPdDHDiSvygLIkvwnSEhZcpk1vlwQ TtxjbAi5FvSRyNI0QZNEgPg5zdviZiPe+AKmkVYEw63Bl7FOshWC08oLk+WwVCuC4Ub+ KXRlYqVDQ4a0Vkn0NcXJhZrBYZz01q1tWNsCDZy1aH8rXE43n6WdabHIQNdARMjT3Urw JaBLtHQRxVNYtc6B3gxAoXgq88LiTLiMakJRmFMHCKVmCGOgf89UW+jfMWoTqqdylBQX 8aiQQTJC+dEvnwkNJYlePJgECAZZy44zPa3B1y7xLCksL6JVG7CPevTA++pTsFZ+FasF 5Q== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2r8ssrmds7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Mar 2019 18:29:12 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2KIT5oe007066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Mar 2019 18:29:06 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2KIT5jh028397; Wed, 20 Mar 2019 18:29:05 GMT Received: from ca-common-hq.us.oracle.com (/10.211.9.209) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Mar 2019 11:29:05 -0700 From: Divya Indi To: linux-kernel@vger.kernel.org, Steven Rostedt Cc: Joe Jin , Divya Indi Subject: [RFC] Kernel access to Ftrace instances. Date: Wed, 20 Mar 2019 11:28:50 -0700 Message-Id: <1553106531-3281-1-git-send-email-divya.indi@oracle.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9201 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903200135 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [PATCH] tracing: Kernel access to Ftrace instances. Please review the patch that follows. Below are some details providing the goal and justification for the patch. ======================================================================= Goal: Ftrace provides the feature “instances” that provides the capability to create multiple Ftrace ring buffers. However, currently these buffers are created/accessed via userspace only. The kernel APIs providing these features are not exported, hence cannot be used by other kernel components. We want to extend this infrastructure to provide the flexibility to create/log/remove/ enable-disable existing trace events to these buffers from within the kernel. Justification: 1. We need module-specific/use-case specific ring buffers (apart from the global trace buffer) to avoid overwrite by other components. Hence, the need to use Ftrace "instances". 2. Flexibility to add additional logging to these module-specific buffers via ksplice/live patch - Having a trace_printk counterpart for these additional ring buffers. 3. Most often certain issues and events can be best monitored within kernel. 4. Time sensitivity - We need the capability to dynamically enable and disable tracing from within kernel to extract relevant debugging info for the right time-window. Example: When the kernel detects an unexpected event such as connection drop (Eg: RDS/NFS connection drops), we need the capability to enable specific event tracing to capture relevant info during reconnect. This event tracing will help us diagnose issues that occur during reconnect like RCA longer reconnect times. In such cases we also want to disable the tracing at the right moment and capture a snapshot from within kernel to make sure we have the relevant diagnostics data and nothing is overwritten or lost. Note: The additional logging is not part of the kernel. We intend to only provide the flexibility to add the logging as part of diagnostics via ksplice/live-patch on need-basis. Please find below the compilation of APIs to be introduced or exported as is. We propose adding two new functions: 1. struct trace_array *trace_array_create(const char *name); 2. int trace_array_destroy(struct trace_array *tr); In addition, we need to export functions: 3. int trace_array_printk(struct trace_array *tr, unsigned long ip, const char *fmt, ...); 4. int ftrace_set_clr_event(struct trace_array *tr, char *buf, int set); 5. void trace_printk_init_buffers(void); To workaround the redundancy due to the newly introduced APIs, we propose the following restructuring - 1. Move the contents of instance_mkdir to the new API. static int instance_mkdir(const char *name) { return PTR_ERR_OR_ZERO(trace_array_create(name)); } 2. Introduce internal static function: __remove_instance(struct trace_array *tr) This will be almost similar to old instance_rmdir which identified the trace_array to be removed based on the name. Modify existing API to use the internal function: static int instance_rmdir(const char *name) { struct trace_array *tr; int err = -ENODEV; mutex_lock(&event_mutex); mutex_lock(&trace_types_lock); list_for_each_entry(tr, &ftrace_trace_arrays, list) { if (tr->name && strcmp(tr->name, name) == 0) { err = __remove_instance(tr); break; } } mutex_unlock(&trace_types_lock); mutex_unlock(&event_mutex); return err; } New API to be exported: int trace_array_destroy(struct trace_array *tr) { int err; mutex_lock(&event_mutex); mutex_lock(&trace_types_lock); err = __remove_instance(tr); mutex_unlock(&trace_types_lock); mutex_unlock(&event_mutex); return err; } ==================================================================================== Thanks, Divya