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 38EB8C28B28 for ; Tue, 18 Mar 2025 11:20:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2833F280002; Tue, 18 Mar 2025 07:19:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20969280001; Tue, 18 Mar 2025 07:19:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 084B4280002; Tue, 18 Mar 2025 07:19:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D49B9280001 for ; Tue, 18 Mar 2025 07:19:57 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E8D4157F98 for ; Tue, 18 Mar 2025 11:19:58 +0000 (UTC) X-FDA: 83234427276.01.8014B9D Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) by imf22.hostedemail.com (Postfix) with ESMTP id E13E4C0004 for ; Tue, 18 Mar 2025 11:19:55 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=QVgvFXCY; dmarc=pass (policy=none) header.from=igalia.com; spf=pass (imf22.hostedemail.com: domain of bhsharma@igalia.com designates 178.60.130.6 as permitted sender) smtp.mailfrom=bhsharma@igalia.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742296797; a=rsa-sha256; cv=none; b=FgmcZVIs7yKRYfmGtRbpsEmEX0ewy7gz3p8EN+2HWHNYCKth8UiBQSjbQbQyOeW3C9k2Vm R2ZExCsYpDbM6FphJh9SQb1LVQjz7HP1NIbgJGhUcDeVrWT9gNPi6MAJFdIF7xnM1rn+sK kJiDRl+Pbpvumib/vPc3sN7Zo/317XU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=QVgvFXCY; dmarc=pass (policy=none) header.from=igalia.com; spf=pass (imf22.hostedemail.com: domain of bhsharma@igalia.com designates 178.60.130.6 as permitted sender) smtp.mailfrom=bhsharma@igalia.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742296797; 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=hgkuz267b67SX+QM0W1jzr7EXhcboJpgPAQwlzu1erE=; b=5/YFAxXlABTdzt1bGo/hitAjiZffOWG6AYSBABv5pIflfz2BzMuVXynAE7wuY+NNTSLaHS MIP8lqkGoSCXtTWG4x9DGTf2IblKEITE8b6k6sB/kyOd36MxIlgGu+Gn6Um2yKcEeYVLq0 4ffsoGx+raAGzOkguT8seurr33Ni7mo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hgkuz267b67SX+QM0W1jzr7EXhcboJpgPAQwlzu1erE=; b=QVgvFXCYTJl4+9Vf0VRaVN892p Ugnl2V4H0E7oMDa5wTSJFhD3Ic4LgwEpDzYh+XQoA30GvMLWVEbkDxDxAiR0EGku0/ObwJixGuR4U EMkNFaPzZRjpv28BXwkdsrzz6pcUvomjPAXX3i5E//wOkW3o2zgeu9pcBb55rQB38pfYSC34QMPQN rI21IZBslc9xdp5oTeMEwlcfnz8E4hp7WmTZEL6pVorsizA6kTgi53Lbx8zRgyiaN3DyDvfiMzNaQ hr64ob7YwQFoqo/uWj8pqc94Zag3D8XQ3TLAanesyUyBimCocC/sUzmb4r+VsiEMQqyeo4xxUG1z7 FBt2bi+A==; Received: from [223.233.71.8] (helo=[192.168.1.12]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1tuUz1-002g2U-L9; Tue, 18 Mar 2025 12:19:43 +0100 Message-ID: <8b11d5f6-bb16-7af6-8377-bb0951fcfb60@igalia.com> Date: Tue, 18 Mar 2025 16:49:28 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH RFC 0/2] Dynamically allocate memory to store task's full name Content-Language: en-US To: Andres Rodriguez , 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> From: Bhupesh Sharma In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: E13E4C0004 X-Stat-Signature: 3ouhku9h519wi5feq8wgjcefwcbx4k9h X-Rspamd-Server: rspam06 X-HE-Tag: 1742296795-682681 X-HE-Meta: U2FsdGVkX19mYcv87fOg7jsfShOUpKJi8RV3Wa0qg/OF66m7SQx18CF2V+r7IVHPKV4ra04uVMbJk9/UyCBX2vIcMfx+/aVo6GlPdT6NJQN9t/6d6Z22IQLs+IbX5ctJGDgmT5Feyyt7OtXcGHTnpRe6qnHNvoh+3ThkCijgfMOCUNNqEt5wU2/d2DO5ro1F5lYsujVuqbYUmV0zlSC+AuBB5q/J1Oa50XCj9CdBqRManZLfujDoOmHsc5SSGCd0pgnV51UmRaDfMzdhm9458yRCGhPrIUHP6fJLWYCF20tGjnLTgl1y1hHddjGBXSaKv+PQsRy00ARsPT19cT7ciWc7tXZ9NtkaVV7nRLmkiO4JZFjtuw9cyPMLYpQ+C4ROtPFSzPixB0qcLWthsxmxhjwSv6IojHKjx/y4VNI1YuX5T2b0HQJRYyqN/CElf7I+EWc58xygVWdG5IgcbexMi/WK6VSfiPhYJL3XAqqdOUnRmgxli+Gd2DK/aEBEFmfmYA0NmuT3kftFX9KZ5Pz5L7voTU5johEzuqjqoToCHPSsieug2Mw77TgfduV6YuZ2CDU2AdSVsYxYkA+Vu+2IW5sZQX106b8C7Qsb7OzOyxyO3YiIJ2QSjbS+Xd+XQ/5uI/a5cI5/1VE6jqhHtQSqP7JJ/fcUWj31muMgtbTZu51hHv4/Yd7+GhUN2Nql9hBLUMeA28L1DGEABBHb28VZ5R0x72vAssc/giJJHgAq14iJV7olnP+eUgxODDfT806mQ7Rv8cEjQ7kqg+tcrQ3vrxJyzHsVtdHCZkMMbvOQ15hVSEfqw/gmn1jfotMryoXoV7wVVsLasijrGFi5JCeFQys4kU1BJWNt6E8DCfNSv0ldHSfFas2v7YX7sZ5B9T9gFtyXNXIPGJmBAdQ4d7N6pLM7kEP3T8KwkXk7SyVAvNiXxfBSbxMDog4ZVwa0bfyw8ftjHTGI0QG4nYKlN0T dr4fI1Rm 38F6nNOxoIVP3adgt83D2lgcS/VxhPrVcxVs9B+Tjl0epMGSjSz71qvGckOr1dZYCQYDl/fXsY9DQoMGqAzp4Yavly9eSPoz0k/3LmefvcrtwnB5Y0BrydurUYQ1b9JZJ3l67A6mild/grjtiEqP99QMG9+ghOnVqycGl+ooTdun+5xXruCfj3h6VzFC/sq75drxtplRCV9UbRD7d6uiKnl8mEzvS1KHXQtS0FH7TDsxf3FQd8jyiEBAOqQE9KNnhTicHlz1A6I1acvr4p0rD1kr6LfkCxNLKFY7ZH7DsFhgYgyNVPMc1UYjTM5w5n4Zg7oY44AM1pBZiW05CEtZ9ANVXJQ== 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: Hi, Thanks for the review and inputs on the additional possible use-cases. Please see my replies inline. On 3/15/25 1:13 PM, Andres Rodriguez wrote: > > > 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. > So, basically my approach _does not_ touch TASK_COMM_LEN at all. The normal 'TASK_COMM_LEN' 16byte design remains untouched. Which means that all the legacy / existing ABi which uses 'task->comm' and hence are designed / written to handle 'TASK_COMM_LEN' 16-byte name, continue to work as before using '/proc/$pid/task/$tid/comm'. This change-set only adds a _parallel_ dynamically allocated 'task->full_name' which can be used by interested users via '/proc/$pid/task/$tid/full_name'. [PATCH 2/2] shows only a possible use-case of the same and can be dropped with only [PATCH 1/2] being considered to add the '/proc/$pid/task/$tid/full_name' interface. >> 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. I am fine with adding either '/proc/$pid/task/$tid/full_name' or '/proc/$pid/task/$tid/debug_name' (actually both of these achieve the same). The new / modified users (especially the debug applications you listed above) can switch easily to using '/proc/$pid/task/$tid/full_name' instead of ''/proc/$pid/task/$tid/comm' AFAIK we already achieved for the kthreads using d6986ce24fc00 ("kthread: dynamically allocate memory to store kthread's full name"), which adds 'full_name' in parallel to 'comm' for kthread names. Thanks, Bhupesh