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 6C4CBC28B28 for ; Sat, 15 Mar 2025 07:43:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0860280003; Sat, 15 Mar 2025 03:43:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB755280002; Sat, 15 Mar 2025 03:43:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95880280003; Sat, 15 Mar 2025 03:43:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 765EC280002 for ; Sat, 15 Mar 2025 03:43:51 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 277DEC1830 for ; Sat, 15 Mar 2025 07:43:51 +0000 (UTC) X-FDA: 83222996262.11.7D27944 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf06.hostedemail.com (Postfix) with ESMTP id 2581B180002 for ; Sat, 15 Mar 2025 07:43:48 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Mm630ki+; spf=pass (imf06.hostedemail.com: domain of andresx7@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=andresx7@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742024629; 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:dkim-signature; bh=rAmL+5CR2z6jEwd9cSjJDC4ozmAh9Z7pTmFVoqfcygM=; b=1dz39HJA5bYuQ+f6A3I+NNZ14iIp/BZWDPYJRyrfQn1GU43AQR2JcpcZxV0xD6kpokkjHd aohBcpdqCc/tJoJC+JmpQ3uRodkoF1hIa6+ZenkUV/05p7Do8FKanmyudf++PC42PWBsRm CmLymb/jjcIma4iDqb3NBbDGwHi/S8c= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Mm630ki+; spf=pass (imf06.hostedemail.com: domain of andresx7@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=andresx7@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742024629; a=rsa-sha256; cv=none; b=ZvDkQEn88zbWTzxpnUeSw6OaibZmJHmnV8TZNcG9T9nwoCb0ZeKKSEvsQiX87+Kpyio/OQ u1UcxflC5yVh51E0KuZFqcs0I52MEXI7w702UlEJznW3LUHI6QBALSV8SNkmmW+PejjHrR Q9006cLxldlXpvibVoAeYL44M4iLVAg= Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-224019ad9edso71273825ad.1 for ; Sat, 15 Mar 2025 00:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742024628; x=1742629428; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rAmL+5CR2z6jEwd9cSjJDC4ozmAh9Z7pTmFVoqfcygM=; b=Mm630ki+vNUnR3Jlr2O1qQTsil92/s1PJXDgClNL2mbQwsTrIROBXG6EgpdCatjDkJ Gfpe911x9CL2AeQeCNAr3XOdKr6WAGdFbdBKBi5g/Ir3GfpNqxFFft/4IrVC4P+5ak3/ PFseNp9c5CPa65+ZLfijO9gQnn96pSyAY4VrcMc7CLIPgMlakPYCEpVX38X0ZR5TKBEY 38LS1VCqiKs8lX6q+yQTi5K50cH1wzrg1NmwBg/eT0ub2ZOV0QGe2vHYfcUStIxzzzxx tZD4MqXP2cCCICBx4WdqCubXOAs6nky0SG53zimI5u3tgn9hgdKwMj3Ofrdmmomq7tXQ T0Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742024628; x=1742629428; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rAmL+5CR2z6jEwd9cSjJDC4ozmAh9Z7pTmFVoqfcygM=; b=Wu44fyXa+OcfFfZQQigufwLfmqNOalRVSP/XZdR5f/6q5lSiWYWbwi+DhqnGMfTHDK BoWRAIstYHaZpGYKVzbYULYxeoEpVrqrozxF2+HsOF8bH/uRdl5jL/bQvm7aFWBT/fhS 8dQUbk62Cxoz49ivD3NmnNihN91PzbbE8+jycyf7qRzmUgD/9Pz0TkhLK5nkAA8KPCyF TWPUTqNxNrc+eCmNlLJFCqW8cdMxOJf3ZxfJEhhVa+3Iiw4ba7OeMx4IPnw55GDK3YTY atm4dHaOoHdvaIDLFXxuUPK4WEUBJ75Gcu76OEwyXBGqX1JEb3U0lLMrjk4GRd6aWJGq WX0Q== X-Forwarded-Encrypted: i=1; AJvYcCVQPrjJ/IN6sUDL+QaWmY5WGRdXh7VgJJ1vYcOigyNR5JwscKV8NE1iunM01sbomyPDXzHcgtXiZQ==@kvack.org X-Gm-Message-State: AOJu0YxBcK2Sf2oR7GyL7WtlYRqieC0h5jvZWIXWDOW1ykPiIpsYEy15 m9aN93hqkByN4c+7BIa6uzwCDuTnMZA2GJwzt8mBgEZ2DklSOAhs X-Gm-Gg: ASbGncvxxF6pv4LQ4rkmze6zAkBLAQyFOfl+4uBSO9ex2ULBzOgzfMXvYaKJHskgSml qtqa6RnlmnLeNYYC2BMqTCLU1VW9Wov6UgZ2R1xUCa8CXRbuzKV8FffgAHZozcJiw3isV9eMTa1 /DH50NAVOKEyPD5v4FChbV1M70xoJMz+xoJjfI8WDfMPjf+/bg3tIG/DNUBwbQUGc/7yx9/FC+b TOsqP68q8mHN2eySFVka/My8t/kNURlliFd5Ri/V0cT+wl0q/y/+zxIk+AR/W77zatcZtNWE3ku pRbOwovPG0CxQ9Oyfbz6nOPNrDT4lKGiZszKcPWq0Wsf X-Google-Smtp-Source: AGHT+IFNXmsiLHb1JHv7bDZUdBco+pV3oLLy0KNHvrNch7t31ViRO39JDS2byJdpYxvminRgrzVx7w== X-Received: by 2002:a05:6a00:2382:b0:736:4e02:c543 with SMTP id d2e1a72fcca58-7372233ae33mr6017160b3a.9.1742024627617; Sat, 15 Mar 2025 00:43:47 -0700 (PDT) Received: from [192.168.0.164] ([50.35.39.14]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7371167df97sm3965668b3a.114.2025.03.15.00.43.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Mar 2025 00:43:47 -0700 (PDT) Message-ID: Date: Sat, 15 Mar 2025 00:43:45 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 0/2] Dynamically allocate memory to store task's full name To: Kees Cook , Bhupesh Cc: akpm@linux-foundation.org, kernel-dev@igalia.com, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, oliver.sang@intel.com, lkp@intel.com, laoar.shao@gmail.com, pmladek@suse.com, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, arnaldo.melo@gmail.com, alexei.starovoitov@gmail.com, andrii.nakryiko@gmail.com, mirq-linux@rere.qmqm.pl, peterz@infradead.org, willy@infradead.org, david@redhat.com, viro@zeniv.linux.org.uk, ebiederm@xmission.com, brauner@kernel.org, jack@suse.cz, mingo@redhat.com, juri.lelli@redhat.com, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com References: <20250314052715.610377-1-bhupesh@igalia.com> <202503141420.37D605B2@keescook> Content-Language: en-US From: Andres Rodriguez In-Reply-To: <202503141420.37D605B2@keescook> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2581B180002 X-Stat-Signature: 9q1g8ecpky6rmru53d3mpayuha8ncifr X-HE-Tag: 1742024628-572078 X-HE-Meta: U2FsdGVkX18alQU0oYZ7gnExyHY1DF4FgU5Ap9evAtnXeNhBktSaFaAuXsCC8UJekZs9pgmb/PW0cJigG/Bq/HuBLfjGCclxt1saMnwBaoxwUyu8yq9XWiFLlPfFd6qc6dZ4TjCC6woXdpNteywsigBMUXzQffljv8Qn7+Wuoo+mChhO+SrGpundW2W9rDQUUDPuJCm4J7dD74HZhFHxHnq4A6gqXA5dr//iJulvhqKF2k/M/BSWva5lmWh+87EC1rPNlpr0Wh8PLrXsHdjG7VCCVh7D0FAmScQ6Ts4220UPC2lhY9xbppjhM0vL4ogzxzau5cK1eDCWdleciVz2RtSzgBnN3E7UbXkddAu8vpcyzxxmkoKZEb8WzwEIluSWuiJ5B/5/WWe1jK9qnWplQC8mT9O715lKr51o6Hb/0GURVwiJNAgUI105osd6qmAp9BBnTz4WNTzfiDtqGqGGHRZTKKq/PWyy/OAtzfbbEkce5CvN1HpAU9svCua3+jyz4Fh5bDj/boevPCfaszh+H+ik9BDO0LhRxkSIbZBlheiXc74kw/+vx36NZ3amdSRhoahuqlMJ0Lrdq/lY0vrLShtsL13a/q5sIRRZ1sTNXeAEZkPX1KarD4RGdPLwk8LsgkCKFtm8tw6JxeGGB+mL9ZYqqgfvdBJJp5n/fpPKzdIIiN0E5aoHZjU520Q5Ti7uCqsyNGgAMnn4Njkl31DBt2i0TMEEadDQsUa7VZ9GAjY2e7LxLrq4kouXC1hdrUbXSETFecv3AmNhUUHOGEDTxn7nMzAcbhrZXwhLiq9Bll0WZazOVMaKWsMOUrQ36UsvO0cCgx1v5B7izlx3xqYsYS0DdEpR16OeJ46efbCir7yKxulxryCHXkDgdrMcLPU1VR2hVt/ZiQ0AKZn+N4VRmZmrxUIlqLdvdO1UUlo91WytWnLvWN0ea4ivs2/SQaGB83pLeemORk5XtWHbARv aKv2ukLL V3sKd+kXZGqbsIrLjMcHMT9cvJF68L2F6ReOjIg80RFtUoH01kMynl8TkfCUi8FUTOtja3YXd5rNVp9IV9Sq4a0Rp7eUm2lSzIc0O/1BsXYcnZVln3c0JW2SbdUVF4cieUQpovbhsQqOqsGMO6wg3zKPZf7UcjHnv8A8mMPEuruRo2NMVP+paBh79oI2zsq/eZ+PlYqO2kuwYABZ6cZfUz0Iz6x3qomWUcIkqIH3N5eatvb5ckZQKvVbQUcVgnQ5szzLu+QetmrCykZe3+t3jRlzdG5HIwzPwyUKLV5meW15tJr+sDXGX7o7CTPqiJIdFpkLxjwgMfHl8/BfyVd0Xs8QJBcDunPUAKgRo1aFhYm3N0iHfurD3TjGogC+lTX92gie33ZDuDI9aQ3aJzWcRZOgUEAvj0CD21K5VeviObmEObxkYp7TKncmVdUC/ABb8mMX9E/dZTQWOX/ApYfz6EJEcYnuqdpNufVZpGudV6NcTpRCzn7pcuj+ORg== 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 3/14/25 14:25, Kees Cook wrote: > On Fri, Mar 14, 2025 at 10:57:13AM +0530, Bhupesh wrote: >> While working with user-space debugging tools which work especially >> on linux gaming platforms, I found that the task name is truncated due >> to the limitation of TASK_COMM_LEN. >> >> For example, currently running 'ps', the task->comm value of a long >> task name is truncated due to the limitation of TASK_COMM_LEN. >> create_very_lon >> >> This leads to the names passed from userland via pthread_setname_np() >> being truncated. > > So there have been long discussions about "comm", and it mainly boils > down to "leave it alone". For the /proc-scraping tools like "ps" and > "top", they check both "comm" and "cmdline", depending on mode. The more > useful (and already untruncated) stuff is in "cmdline", so I suspect it > may make more sense to have pthread_setname_np() interact with that > instead. Also TASK_COMM_LEN is basically considered userspace ABI at > this point and we can't sanely change its length without breaking the > world. > Completely agree that comm is best left untouched. TASK_COMM_LEN is embedded into the kernel and the pthread ABI changes here should be avoided. > Best to use /proc/$pid/task/$tid/cmdline IMO... Your recommendation works great for programs like ps and top, which are the examples proposed in the cover letter. However, I think the opening email didn't point out use cases where the name is modified at runtime. In those cases cmdline would be an unsuitable solution as it should remain immutable across the process lifetime. An example of this use case would be to set a thread's name for debugging purposes and then trying to query it via gdb or perf. I wrote a quick and dirty example to illustrate what I mean: https://github.com/lostgoat/tasknames I think an alternative approach could be to have a separate entry in procfs to store a tasks debug name (and leave comm completely untouched), e.g. /proc/$pid/task/$tid/debug_name. This would allow userspace apps to be updated with the following logic: get_task_debug_name() { if ( !is_empty( debug_name ) ) return debug_name; return comm; } "Legacy" userspace apps would remain ABI compatible as they would just fall back to comm. And apps that want to opt in to the new behaviour can be updated one at a time. Which would be work intensive, but even just updating gdb and perf would be super helpful. -Andres > > -Kees > >> will be shown in 'ps'. For example: >> create_very_long_name_user_space_script.sh >> >> Bhupesh (2): >> exec: Dynamically allocate memory to store task's full name >> fs/proc: Pass 'task->full_name' via 'proc_task_name()' >> >> fs/exec.c | 21 ++++++++++++++++++--- >> fs/proc/array.c | 2 +- >> include/linux/sched.h | 9 +++++++++ >> 3 files changed, 28 insertions(+), 4 deletions(-) >> >> -- >> 2.38.1 >> >