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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D952FC433FE for ; Wed, 23 Nov 2022 08:01:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235794AbiKWIBG (ORCPT ); Wed, 23 Nov 2022 03:01:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235733AbiKWIBE (ORCPT ); Wed, 23 Nov 2022 03:01:04 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C598F101F6; Wed, 23 Nov 2022 00:01:02 -0800 (PST) Received: from dggpeml500021.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4NHD415fBJzqSdg; Wed, 23 Nov 2022 15:57:05 +0800 (CST) Received: from dggpeml100012.china.huawei.com (7.185.36.121) by dggpeml500021.china.huawei.com (7.185.36.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 23 Nov 2022 16:01:00 +0800 Received: from localhost.localdomain (10.67.175.61) by dggpeml100012.china.huawei.com (7.185.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 23 Nov 2022 16:01:00 +0800 From: Zheng Yejian To: CC: , , , , , Subject: Re: [PATCH v2] tracing: Optimize event type allocation with IDA Date: Wed, 23 Nov 2022 16:01:33 +0800 Message-ID: <20221123080133.1128186-1-zhengyejian1@huawei.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221122223258.10faaf4e@rorschach.local.home> References: <20221122223258.10faaf4e@rorschach.local.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.175.61] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml100012.china.huawei.com (7.185.36.121) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-trace-kernel@vger.kernel.org On Tue, 22 Nov 2022 22:32:58 -0500 Steven Rostedt wrote: > On Wed, 23 Nov 2022 11:18:06 +0800 > Zheng Yejian wrote: > > > But Yujie Liu reported a problem that highly > > reproducible after applying this patch: > > Link: https://lore.kernel.org/lkml/54f23c9c-97ae-e326-5873-bfa5d2c81f52@intel.com/ > > > > So please DO NOT apply this patch before I find what happened about it. > > I know what the issue is. > > The current way of assigning types is to always increment. And not to > reuse until it fills up. And even then, it looks for the next available > number. > > I'm guessing the IDA will reuse a number as soon as it is freed. This Yes, it is. > may also have uncovered a bug, as in reality, we must actually clear > the tracing buffers every time a number is reused. Thanks for your explanation! It seems almost the case, and with current way of assigning types, this problem maybe also happend when reuse type id, am I right? But instead of clear tracing buffers, would it be better to just mark that record invalid if we had a way of knowing that the format had changed? > > What happens is that the type number is associated to a print format. > That is, the raw data is tagged with the type. This type maps to how to > parse the raw data. If you have a kprobe, it creates a new type number. > If you free it, and create another one. With the IDA, it is likely to > reassign the previously freed number to a new probe. > > To explain this better, let's look at the following scenario: > > echo 'p:foo val=$arg1:u64' > kprobe_events > echo 1 > events/kprobes/foo/enable > sleep 1 > echo 0 > events/kprobes/foo/enable > > echo 'p:bar val=+0($arg1):string' > kprobe_events > > # foo kprobe is deleted and bar is created and > # with IDA, bar has the same number for type as foo > > cat trace > > When you read the trace, it will see a binary blob representing an > event and marked with a type. Although the event was foo, it will now > map it to bar. And it will read foo's $arg1:u64 as bar's > +0($arg1):string, and will crash. > > -- Steve