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 03F93C25B78 for ; Mon, 3 Jun 2024 22:39:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CE336B0099; Mon, 3 Jun 2024 18:39:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87DD96B009A; Mon, 3 Jun 2024 18:39:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76C676B009B; Mon, 3 Jun 2024 18:39:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 562496B0099 for ; Mon, 3 Jun 2024 18:39:10 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 04AA840AC7 for ; Mon, 3 Jun 2024 22:39:09 +0000 (UTC) X-FDA: 82191044460.06.815551E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 67D4E120003 for ; Mon, 3 Jun 2024 22:39:08 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717454348; 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=dM5djux4B7U2WW16KMjOhhGaxS9EJBjSC0Y78XYzP7s=; b=WVeek9w/frC1zVavLMXO5wY7GeSgAcqVNbN4disf6hwFdIvdXNbxKDB2Q9kWH1uTZnNGRx f5vm7ZBQW9YEI13G3KEZtBDXpdvkfbmGdpvUi0ZSuDejAEHR+bd1Cf+EuWaMKDw4+9aPVV p5YahILLCG1pBKaUrThzrLbNAa7FhPE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717454348; a=rsa-sha256; cv=none; b=bj2Mf+x+0hhk7V2YEo57QJRSDNSdRwOF8UMoXDfvLRzZ6n09xyQsNmu15XVO1KGKmJwqDB jA+cZQwOMGZISXTGwMQCKxyjaHwH3A+jMnHshfftCGqa9cN5ZuRty6cCeYZbwHpgrgl3WF Q9r/Z+AWHDvPJojsfME6FayKWV64JmQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B161260EDD; Mon, 3 Jun 2024 22:39:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A673C2BD10; Mon, 3 Jun 2024 22:39:05 +0000 (UTC) Date: Mon, 3 Jun 2024 18:40:16 -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: <20240603184016.3374559f@gandalf.local.home> In-Reply-To: <20240603183742.17b34bc3@gandalf.local.home> 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> <20240603183742.17b34bc3@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-Rspamd-Queue-Id: 67D4E120003 X-Stat-Signature: 8apmff5gqh8gns9waeeaqkad4y8tekgm X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1717454348-370014 X-HE-Meta: U2FsdGVkX1/qQPoeTtalhQoo/gWX5EaHoEWGKaMdHHSs7UjPWbQTTNxAIjeHYyF4DoO7NuDRSl8y7F8TvzWXl7tbpa8HKSI+wcEysj9Qd9JTAdzOKFDrONmTjXuwQwB4n2AbbSDjqqRiUW6aEC5NlYT+ZZy0G/MfZ1hzgD7PJiSVFziACtPRWRO6R4nbCAf+7iwfuhDGNXLLM0tVqep1L+fFkg0DZh2l/jqF8vGv/C+f9KjjIgc5qyOhkblHMzhTP9wgacKZVpRE+QLWKsHX/iN7Gr9FqDioUEDVccybzZGY+33RJk3pr+OJgGKfaeKo7QG4gjRJk6lS9kqpHYosNTBvdmztDhIJCAEnmbqzYvJ4r2Y77c4560bU05wBh4ailx0wOQqcwA5zKa24XTtDuB+Ujs3Tkv7ovRaIY8ItUPYHbfY/rCWaqSYhKEk9faA995RC5v7zxG2ziXXEygy6CivH1oCRPciZzaSJTfekB0gu5IJhP5ePB4NNyZt62chxv+TTV8p9ttOG35iAEWAEyWY0ZGLcvTYT6iNEytxTIEajNfh00EFWZ0Qu+xRzjh4p88chc6Y5PgvW0Al12lIMIJRYx98VrXqKC53SnsqNK1Cm4/30LknGK4BKdA2dVSb3gEniwPBaEQ1f8R5ttjotjlJ/kgk5TJRtSLPQAW1uUKDzAvZyA7vhXt4N7Qx3jXsWFoRck3ODRHN7WCBKBZIR38LjjefQGTnmRA5l9dr3E7ef2qDyEtj+iNVdgbGqcydnc/QJvzhszxkWu6G30w0uilf87gbrlNCbnHS10prkWGEfgy27EKvw/8bfMDMJ1SISplQHU2jGwHrm+nupBnJV8YJzZDi3P1BGGcHXTAMDcSaAiXFfI81kCHFA1pb5P/oYrmyEkdsfR+ph9expbUhPPkhelE5cODdanyUZ1FzrDlpjpJnz8FvfQArEw8vrLmWMGcXELyI+9RUwjn8qvnf 7bQ1uGxl WYfCW9dZJ6LAplAG7P95WWZ5qnutv8fCPuEjDLlSUWJXXgcw/+5uKWeWqkzkQuZ3XUMGmCjOxyQjrzOm2APxbze0B47sJ0vm4X4lIMufIfyAIVt5cwLh+VTNy/uCFkk8KV+EvZUJhr9oZ3YveEKUfWhjHCNz9H1XNNu5jDOh/I+APBXgyyQNR8Bv6y7Q8dqdkJEUoYSjsYvZGm99tSGq2XlvS+2u9l+Rp3gMoxLkFIlMUIivT84ztgsdiFQEH+5UhAWyIumnC2cqK5eX6QXo/OhrWJptgQfQk/zcEa02kcz1XIyqt+lU+4UA4gXjldVJsUH1FSInZf+ZXEJaL8bwXDMR2tSv5KUIUYmfVhNP2Lxj0hnZctfi2BNflGnRWABxXAHwA0qd5T3cgKJTu8qcxJY3rBd/j6p82ZV+LjlMEJfocCbUfheQYA+3aqiAyUBrtZodZ3Tk+Gm4Tz74= 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 18:37:42 -0400 Steven Rostedt wrote: > 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. :-/ My point is that if we are going to be changing the way we record task->comm in the events, might as well do the change I've been wanting to do for years. I'd hold off on the sched_switch event, as that's the one event (and perhaps sched_waking events) that user space may be have hardcoded how to read it. I would be interested in changing it, just to see what breaks, so I would know where to go fix things. But keep it a separate patch so that it could be easily reverted. -- Steve