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=-9.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham 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 88730C3A59E for ; Tue, 20 Aug 2019 23:09:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 50DF02339E for ; Tue, 20 Aug 2019 23:09:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lekensteyn.nl header.i=@lekensteyn.nl header.b="Ncim4CHF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726362AbfHTXJJ (ORCPT ); Tue, 20 Aug 2019 19:09:09 -0400 Received: from lekensteyn.nl ([178.21.112.251]:41075 "EHLO lekensteyn.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726354AbfHTXJI (ORCPT ); Tue, 20 Aug 2019 19:09:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From; bh=Q+UDWMYEYIrMXXf99yl5++TT8RhBbJ8ffMGbmG6M8fY=; b=Ncim4CHFR1Q5+pd5BNiNHzCvws2Ijii1/CviLZYp5ZSWR4Knp+bFWtUXA4inj+VXxP/LbmslA8R0lI+PQszg7deLDswysKr8qIESiNHsUEg3fpY3T2WheqhouGW6ViDxZKJqPo0FYcuaHnT7A35lEKVss95cKOjpB23BLJ/RIPUimBmtZoZawJtSzRQmdzanEaEHM2WAxLzQof1XsglWFMlQZvZqrMkrWmTvWdHvAtDtrXyPU9HNWjnlIaN0e2oTtV8p4EcWyUUyvn8bMyRKk80RLyX8POgnhIX2G3hIJlaEKIdtmivX62gLQIip1fFKrkMGABkjKA+zKqSVO+AtfQ==; Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1i0DFR-00055S-D6; Wed, 21 Aug 2019 01:09:05 +0200 From: Peter Wu To: Alexei Starovoitov , Daniel Borkmann Cc: netdev@vger.kernel.org, bpf@vger.kernel.org Subject: [PATCH v2 3/4] bpf: clarify when bpf_trace_printk discards lines Date: Wed, 21 Aug 2019 00:08:59 +0100 Message-Id: <20190820230900.23445-4-peter@lekensteyn.nl> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190820230900.23445-1-peter@lekensteyn.nl> References: <20190820230900.23445-1-peter@lekensteyn.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org I opened /sys/kernel/tracing/trace once and kept reading from it. bpf_trace_printk somehow did not seem to work, no entries were appended to that trace file. It turns out that tracing is disabled when that file is open. Save the next person some time and document this. The trace file is described in Documentation/trace/ftrace.rst, however the implication "tracing is disabled" did not immediate translate to "bpf_trace_printk silently discards entries". Signed-off-by: Peter Wu --- include/uapi/linux/bpf.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 9ca333c3ce91..e4236e357ed9 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -575,6 +575,8 @@ union bpf_attr { * limited to five). * * Each time the helper is called, it appends a line to the trace. + * Lines are discarded while *\/sys/kernel/debug/tracing/trace* is + * open, use *\/sys/kernel/debug/tracing/trace_pipe* to avoid this. * The format of the trace is customizable, and the exact output * one will get depends on the options set in * *\/sys/kernel/debug/tracing/trace_options* (see also the -- 2.22.0