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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no 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 CECD0C433DB for ; Thu, 25 Feb 2021 02:08:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7297D64ECE for ; Thu, 25 Feb 2021 02:08:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234790AbhBYCIY (ORCPT ); Wed, 24 Feb 2021 21:08:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:52278 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232662AbhBYCIY (ORCPT ); Wed, 24 Feb 2021 21:08:24 -0500 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4F0EB64E02; Thu, 25 Feb 2021 02:07:42 +0000 (UTC) Date: Wed, 24 Feb 2021 21:07:40 -0500 From: Steven Rostedt To: Andrew Morton , Joe Perches Cc: cl@linux.com, iamjoonsoo.kim@lge.com, jian.w.wen@oracle.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, paulmck@linux.vnet.ibm.com, penberg@kernel.org, rientjes@google.com, torvalds@linux-foundation.org Subject: Re: [patch 014/173] mm, tracing: record slab name for kmem_cache_free() Message-ID: <20210224210740.73273c7a@oasis.local.home> In-Reply-To: <20210224203708.4489755a@oasis.local.home> References: <20210224115824.1e289a6895087f10c41dd8d6@linux-foundation.org> <20210224200055.U7Xz47kX5%akpm@linux-foundation.org> <20210224203708.4489755a@oasis.local.home> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org On Wed, 24 Feb 2021 20:37:08 -0500 Steven Rostedt wrote: > > + TP_printk("call_site=%pS ptr=%p name=%s", > > + (void *)__entry->call_site, __entry->ptr, __entry->name) > > You must use __get_str(name) here! > > (see other users of this logic in include/trace/events/*.h) > > What is happening is that TP_fast_assign() is called by the tracepoint > logic (at the time of the event), then much later (seconds, minutes, > hours, days!), when the user does a "cat trace" of the file, the > __entry->name is read and the printf logic is called against it. Well, > the s->name that __entry->name points to, can be long gone by then! > > Instead, using __string() tells the TRACE_EVENT() macro that this is a > dynamic string. The __assign_str() records the string into the ring > buffer. The __get_str() retrieves the string from the ring buffer as > part of the event, so it stays around as long as the event being read > by the trace file is around. > > Please do not apply this patch as is, it is very buggy! I wonder if we can add something to checkpatch that can check if TP_printk() has a call to "%s" where it references a __entry->xxx and not a __get_str(), and will warn about it. There a a few cases where its OK. Like RCU uses a TPS() macro around strings it passes into the tracepoint, which is used for strings that never are freed, and maps the string pointer to the string for user space. But RCU is the only user of that I believe. -- Steve