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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5130C25B75 for ; Mon, 3 Jun 2024 22:36:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34CC86B0096; Mon, 3 Jun 2024 18:36:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FCDA6B0098; Mon, 3 Jun 2024 18:36:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C5BD6B0099; Mon, 3 Jun 2024 18:36:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F26796B0096 for ; Mon, 3 Jun 2024 18:36:36 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 96977A21CF for ; Mon, 3 Jun 2024 22:36:36 +0000 (UTC) X-FDA: 82191037992.04.006F5C2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id C32D540016 for ; Mon, 3 Jun 2024 22:36:34 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of "SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717454195; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HUVE30LajRRuvGQrOKxHnfZiZ6lgC1xKVsAq1Fehq+s=; b=plyQH0q6VpRjbjiEw5c7dmXjlzZeRfMQ8pTvuyRAm/WFvSTVAwNwfLfXzoMDIynFP+WnQ9 hn7yPpgjo1V20mjzcNL109eas0oZQLeLjHCySEnZ/KH73SkkJWGuwb5P1Es9WK/8N9ghuT qaQXXVUhxBFTBHxiAswRHgO68ACkv6c= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of "SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=/hzC=NF=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717454195; a=rsa-sha256; cv=none; b=ddKrRWubmqKf+G/C41UdsUehuVEWfWMm0oDGhmrwjBUDtSlmAE3dGP4XvBDZD5GYywSa1O WGEx2Wni2ldKOc5anqA2qKCpQD9xpkXYEPzC1ujoNCf0WuT6gAITgWu+UCEeF00nWh+Myl xWLR3UwczUQxG9ZMU6sB5pdeYeuWuRY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B091D60B20; Mon, 3 Jun 2024 22:36:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF7A3C2BD10; Mon, 3 Jun 2024 22:36:31 +0000 (UTC) Date: Mon, 3 Jun 2024 18:37:42 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Yafang Shao , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, audit@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, bpf@vger.kernel.org, Masami Hiramatsu , Mathieu Desnoyers Subject: Re: [PATCH 2/6] tracing: Replace memcpy() with __get_task_comm() Message-ID: <20240603183742.17b34bc3@gandalf.local.home> In-Reply-To: References: <20240602023754.25443-1-laoar.shao@gmail.com> <20240602023754.25443-3-laoar.shao@gmail.com> <20240603172008.19ba98ff@gandalf.local.home> <20240603181943.09a539aa@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C32D540016 X-Stat-Signature: m86yqbdskd8onzyn71m5i4qs4d7iraii X-HE-Tag: 1717454194-582060 X-HE-Meta: U2FsdGVkX18lGlhLC6HCfPhY0UOooEwRF4SOCsMRjbOuOK4qpwHW3t3tKcspH3KxrTfpHavhGoFNKanhgz01dADyDLMDwmORBLznkLinwf3zYNoqPVClT8lytjY20+5NgFUnABYDTk3VUCGARUgGRgbxs4WtNXbpslaumJh3swZfGw4rYjtwGcdqNo+biP+rRjVCN5/WlJKROOlQv9um3RkgQbH++sIK/AYUtmaI0zMwnt+lgAlKjDdgSgcBw5ZMu0kBmAx+8MAjDmf/yM6jSBgPWNwdZLH5MMEFvgkPEb7Sg7jROX7V3mcXhSwy3EzCyTRG3KPvSVBXSQtbkmpAbwujM2iYiftaaeB2LOt8Ft3OZjVnQMej/+9KzitDWIFvIwEpaMvGvdv9yPTQFemz06lJkYz1BGSAK6aEcwDz/XbYASO+JJtpUSR3kGzE2wti3c4fTi0zeIlnkN0hpjdpYN9mSLZpIbc/Drb3efB6IShnxPnXWxQUDx5+G6XbMK9R5fHRhvsX1vDkGlbRmL0KBEe56AUdiSgcCJjC5pIiOzAq1cgiSiGV3q6P/129wq3vgxlNTJpBuIQR1Kqt7KgknJUW0Sus+Ek5KU1PJzudb+RhCiZ4ZzdPP4oepfJBrFmM4Zc9WYuGG5l5KwFHPrPF1QRnISyfmdxGnjgYOI7/1lLhpleqqAlfwwOBZ+2fC7/Ue5KcknDvmfR21I6rZ9m+uITLAIJ5JZKHzpXRXab/GQ1zAAR+E4eu5kJy+KfjnIK5879ACal+fv1K62emr1J7xtb06aPRSobuLbNQ+EGOTfksILd/2flIViT4qfbuK4/2gjy3uBoqw5bGB4TVm93TLi5T9mmC3K10bAmKW/YbfJbpoUi6SnfqE9+8xhv9JRsOzAGEX1R7mlT2yMVq/M7tLeZLEMvFKmifNblFjcRN6EhxGyPeFyomFWE2Kd0VamGPY0Hnlfe9MM3nkAzloxe iMZrdvhk WqX1vgp9EHITyjG1IF0tR0HfwdvB5E3SrQRYnLyNiS0nqIuY2cYHtFzdtwdpCTv8A+z9C8dhp0FgYeGeJmINlbEH87tIr3dk6RumInRypReRzIgOSVqfhiZgQEtLDs5L/n7n530Z/+snkn80DjbY4bBmt+q8Om/H19jyVev9he0NDAEY9m7ZfloZFFFyYYYHIo7C0e/hFdRNgZt9bAklq3mMJAGbAwy8fTgeufA+pknd0Lq+AAeA7C0uRwgqlkV7ovPYqCMwWgfIr5tFn07iTkF4uI2mPcmOTCtOc6Vr4WSxJkokH0WDnPF/oZsAjawORvBng0+Wn41ETgbRRLsL3jALosBYKXJkMx/0vRwJnvx1hHtzFXAkDj0y8+mhSpD/4f0XOIDLS31POQRFxSlAQL4UOQd5FagjhZlA7H7UfEqcgHyhZuI6DCxI+jfdJgNcsijqZNmOpsgrV3tXO2ok0CXOYA5QgLjxPGNFHPk5k9pjQq1s= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, 3 Jun 2024 15:23:48 -0700 Linus Torvalds wrote: > On Mon, 3 Jun 2024 at 15:18, Steven Rostedt wrote: > > > > The logic behind __string() and __assign_str() will always add a NUL > > character. > > Ok. But then you still end up with the issue that now the profiles are > different, and you have a 8-byte pointer to dynamically allocated > memory instead of just the simpler comm[TASK_COMM_LEN]. It's actually a 4 byte meta data that holds it. __data_offsets->item##_ptr_ = src; The __data_offsets is a local helper structure that holds the information about where the string data will be in the ring buffer event, while the event is being recorded. The actual data in the ring buffer is a 4 byte word, where 2 bytes is for the size of the string and 2 bytes is for the offset into the event. If you have a task->comm = "ps", that will take up 12 bytes in the ring buffer. field: 2 bytes: for where in the event the "ps" is. 2 bytes: for the length of ps. Then after the data, you have 3 or 4 bytes to hold "ps\0". (the data always ends on a 4 byte alignment). The amount of data in the ring buffer to hold "ps" just went from 16 bytes down to 12 bytes, and nothing is truncated if we extend the size of comm. > > Is that actually a good idea for tracing? > > We're trying to fix the core code to be cleaner for places that may > actually *care* (like 'ps'). > > Would we really want to touch this part of tracing? Note, I've been wanting to get rid of the hard coded TASK_COMM_LEN from the events for a while. As I mentioned before, the only reason the memcpy exists is because it was added before the __string() logic was. Then it became somewhat of a habit to do that for everything that referenced task->comm. :-/ -- Steve