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 57BA7C36010 for ; Sun, 6 Apr 2025 02:29:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C18E76B0006; Sat, 5 Apr 2025 22:29:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC7136B0008; Sat, 5 Apr 2025 22:29:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A67546B000A; Sat, 5 Apr 2025 22:29:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 88CBC6B0006 for ; Sat, 5 Apr 2025 22:29:15 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 78DBBAEEC9 for ; Sun, 6 Apr 2025 02:29:15 +0000 (UTC) X-FDA: 83302037070.30.2934A64 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf24.hostedemail.com (Postfix) with ESMTP id 8DD7E180003 for ; Sun, 6 Apr 2025 02:29:13 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ta6HxBR2; spf=pass (imf24.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=laoar.shao@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=1743906553; 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=CIiylM2j9zQF/1YnJzm9yePwxAWbQcx1fkMSx40gJuk=; b=Yox7v6uHLiW07EXoW2U/D2lZ9YqErkAEb1bn6CnLCf9W+eukyxEmLk53JhgP+SInJ9pBT1 sCFFqCGQQu+KwmG8uNxmssvRwnvARtPFUhhZqYM0Zja+RASRX1eEzHrjcVB5mu3ldztckj Jgfb0yiuGt/PDf4VaLRXuRnOe4hOYFk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ta6HxBR2; spf=pass (imf24.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743906553; a=rsa-sha256; cv=none; b=E/R/h1m9SV/V0V7LweVqEG5Yu2fe1bIY3PjYFTc6A7r3evOk/Z26zdV+4Lt8t0qNqTz+6N ONWRQn4LYzZYxB6WpBYIFSHlmJLRVpt46gIDBJPHSuLhiPNjM7dTx5dQraF0KHMloW1oL8 iIfgK78mpRiDop8t52cNotEXlgCRksk= Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6eeb7589db4so34718916d6.1 for ; Sat, 05 Apr 2025 19:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743906553; x=1744511353; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CIiylM2j9zQF/1YnJzm9yePwxAWbQcx1fkMSx40gJuk=; b=Ta6HxBR2T1eMJOcvEVxQSxw8L+bNSGE1gHFgweAjneewUbQ4wlsJdJqhUCBSZeb6hc 9w99a8s3h4dbTezG7PtcXRqUljYK+zrJvsLhDnbt86TYPf+kBUSMnDSGx7AeYZgEB+xT JKrLpH5boUV6JAoo1CcqApy2PCax8gkP8VvmN3kN67YY5Reku8qsWb2915GEB11WW5VG N44MLmkRnk/907r6w/rKpB+2kzJsYltiHRCQFIiH1ja4IUctJg8vQghzy2dUmSnZDXbt 6yAeVLy7y6q4D60uj1qjfVPdAyxIxvL6fzSQcPBafANCpRpt+74MCevK77FrPI1CP9hM TliQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743906553; x=1744511353; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CIiylM2j9zQF/1YnJzm9yePwxAWbQcx1fkMSx40gJuk=; b=eLtYExEaSlZqgcVdx2Q1hTN6cOXClKiRmOCS22w1m92j4u6fTXkQBpsR1nbpEFEYU6 8PNH/vgSCd1ri8Ay/66rUr8cDJf+MBE6inSwyg7M5oNk7jlhmplEC89ZfE2Vaab9IMdu 1uMkB2Ldt2hbqNvLq6Y+jajLgDI12IBZQL6CpP8BCVGiAg6m0xDxRF+lmwKH8jB4cO0W Re760RtEc/QHeY1vMsRxeqQDihCDV8Za5g11LccTVS0ms4ehdwbqWY+vWxzhJdtBSGtz 55Kv3kJktdvvyG1hudwcJTP4Ck88vP1pJf63AMLxqc8pHyP4gj8kiyc/VWFlT6AUao5o mTNw== X-Forwarded-Encrypted: i=1; AJvYcCVfoxhuzmDlTKFE/B5fJsxM2Cv0hzSUYQFUaPNvXlxR/Ztrbq3FGC/mKZzXa3sy8vwwCEp6ZsMmvA==@kvack.org X-Gm-Message-State: AOJu0YwMDTSL7NMDZSvaoN9zxIr9zYhhBnU9VlKUKcqrE64rNWOZuqlh yWbvz3REMpkYjz5bfZ6ie7Qz/2rIcP5IL6hMpK8E0DxjD8tAZO/x4y8/w0d6VDWeHzIznvQV7lg aV1tDnevbJoqPQD5pR2pb9HQhFhw= X-Gm-Gg: ASbGncuBJYkf7wEJq3tvE/vFF63hXQ1+S3EnnZIAoc0HBzKT9LpErvAwcUjVvhE+Yi0 6JelH/vHCkSzeqnDZwNvNG5dQQzJpjemmonBoBR9NxIaD85TVpjB3KtbUiol3WTxJNiTvc6KM7w 0LLsSMHMfu/ad9FeCRio+WR6T2/c4= X-Google-Smtp-Source: AGHT+IGS6yvI0ZrRHzw3B/bNPjznQvxjxVF/nePT6AW/hLY+icoun8BTFzmTjAUxyoEUlJrRWte4+c8X7BaV5K1U6WI= X-Received: by 2002:ad4:5948:0:b0:6ea:d393:962c with SMTP id 6a1803df08f44-6f058535e23mr100523026d6.30.1743906552498; Sat, 05 Apr 2025 19:29:12 -0700 (PDT) MIME-Version: 1.0 References: <20250331121820.455916-1-bhupesh@igalia.com> <20250331121820.455916-2-bhupesh@igalia.com> <6beead5a-8c21-af57-0304-1bf825588481@igalia.com> In-Reply-To: <6beead5a-8c21-af57-0304-1bf825588481@igalia.com> From: Yafang Shao Date: Sun, 6 Apr 2025 10:28:36 +0800 X-Gm-Features: ATxdqUEO5JDPKu66gRn-W6p4DyZydEyISAr6eMeFr_OFfhxP-niPWJgczuY4Eew Message-ID: Subject: Re: [PATCH v2 1/3] exec: Dynamically allocate memory to store task's full name To: Bhupesh Sharma Cc: Bhupesh , Linus Torvalds , 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, 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, keescook@chromium.org, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8DD7E180003 X-Stat-Signature: a5pazktjoye1qiwp374kjsq4xq6rb33k X-HE-Tag: 1743906553-7064 X-HE-Meta: U2FsdGVkX1/3Rslmg4P26yZpekNBfpeWZtxGXNNZAmllArM0BfGmu9Sm+jJPS9HIfLx5c0eUZLrMN54MTvXckF7zSHnVUaUs0Yjf+4SawJ78I9tzinkiwpPwwmARWC2gTkvu3nl9V03Kict39TCF68KSoI46NZOlL9vcbbU+BLPpl41WK9zctz3w6a9AhPmij+DBZojCLJgcnQqZByw6NtiQg77+zuqV/rgmPOslTRjTSH8EUttOIQnpI3HiH5OfvO/++shttE9ntRKn7k9HZzj7jEDgrqtm9uGvDTe9lNm8wjf8gZ8ys8Jn8Eop2SJggVCsx+DPDY0Cdd6iDmdJiw3c2mC+GtSA7lc4Pq7H5prk2lD+hQkLeYNw5iQRLqcymJbK5OgjpRQDUir3g4gbyh9vso7RpbMseqNn7U+dJrysC3Dsj0od7svLGlKfiMHP+bWixw5kploTj1HDlIwYMicOVgiXZ4n+TT8L/9tX7eY18IpdKWBfki/j1vS9APd+6Y/C77N1M/PeGI/RRXh+BDmQEvBFcpCxqwxlDN5vFmZf6jnCdvQBrNTDRMOwf0XBYd3xXxtp3lTTG49CzAf5wQle7HQzPEAqwqBmLMIc7jujOPMJkGgON/WraO5euVit9ihKC5xgvlYYInxt5TtewaPutvmH+YyQ9ldbRVuHHPE0/wvIjfjZBEdtr1/VB2GbV96DC6dZ4nn3AJADutLGyJF5H5+WMEeuQ129JxwvnfPwiVZEkpacY234ye5i6sCzf2g9FGyAYGBUB4S7zM1Qm8OVxWrMgmpUrTAt/3ppYJGqObsrkWiMfDcFWda7DGqkHVgZZy5jFMjNggRMrDHi1tLLtd8rYPOwOtsLTglVPhCpXIsztavCQWPJWZFg6g99AUki78HXiB4UxIDYHjF3zUo678sSEW8YUvvan/1hp2x9ZBzsnMmynnPSb3i2VzSOqvERNlQqPiaQTVl/Ebj lZ9MkTl1 z3g5pK2PJCtTWbsszuuqVNinq9uzgvqNuP9amnmL6oGBa7eZK0842B12OSWtAdddf1oJBwHzAwLRe5eMSCRG6u9dkiOYk4knIxULaQzr0tZrqc5lZ5xeXLdSp/DAiZ8ncDfITpIxt2QjQ3gS3z66aeF2+yi8WjIIl/puWwyXugBYN+mQM5bLcA0iDrWzh8KZcxkFlQrfCm6yeXiQguUeFtpqXTLgGstJmc3QMVlomEuS/oHxYaASwTVMbQrKUgl58M6y6fQ6q24hyXdt5c66xNjgYzx50EWWsBo786OM9kqYv89GSC3LYypBGI/+9nF9mj0BKcvEpPeGZVD5oiPYaPlQzQfe3DNkjc+6lMLMqGrfR6VRK24Ub0euuvXO+d5QJZtM0Bc/9r4RjRU2JwY908ciRRNfaOT0yNO1WPxtbYyEgrCapquk37S5C8WjWu8QiQWgkAe4mm4eZw/jMpoIIB4tLzzTUYQPxwR9OltnsfgzOzA3DaLAEb6F5ZQ== 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 Fri, Apr 4, 2025 at 2:35=E2=80=AFPM Bhupesh Sharma = wrote: > > > On 4/1/25 7:37 AM, Yafang Shao wrote: > > On Mon, Mar 31, 2025 at 8:18=E2=80=AFPM Bhupesh wr= ote: > >> Provide a parallel implementation for get_task_comm() called > >> get_task_full_name() which allows the dynamically allocated > >> and filled-in task's full name to be passed to interested > >> users such as 'gdb'. > >> > >> Currently while running 'gdb', the 'task->comm' value of a long > >> task name is truncated due to the limitation of TASK_COMM_LEN. > >> > >> For example using gdb to debug a simple app currently which generate > >> threads with long task names: > >> # gdb ./threadnames -ex "run info thread" -ex "detach" -ex "quit" >= log > >> # cat log > >> > >> NameThatIsTooLo > >> > >> This patch does not touch 'TASK_COMM_LEN' at all, i.e. > >> 'TASK_COMM_LEN' and the 16-byte design remains untouched. Which means > >> that all the legacy / existing ABI, continue to work as before using > >> '/proc/$pid/task/$tid/comm'. > >> > >> This patch only adds a parallel, dynamically-allocated > >> 'task->full_name' which can be used by interested users > >> via '/proc/$pid/task/$tid/full_name'. > >> > >> After this change, gdb is able to show full name of the task: > >> # gdb ./threadnames -ex "run info thread" -ex "detach" -ex "quit" >= log > >> # cat log > >> > >> NameThatIsTooLongForComm[4662] > >> > >> Signed-off-by: Bhupesh > >> --- > >> fs/exec.c | 21 ++++++++++++++++++--- > >> include/linux/sched.h | 9 +++++++++ > >> 2 files changed, 27 insertions(+), 3 deletions(-) > >> > >> diff --git a/fs/exec.c b/fs/exec.c > >> index f45859ad13ac..4219d77a519c 100644 > >> --- a/fs/exec.c > >> +++ b/fs/exec.c > >> @@ -1208,6 +1208,9 @@ int begin_new_exec(struct linux_binprm * bprm) > >> { > >> struct task_struct *me =3D current; > >> int retval; > >> + va_list args; > >> + char *name; > >> + const char *fmt; > >> > >> /* Once we are committed compute the creds */ > >> retval =3D bprm_creds_from_file(bprm); > >> @@ -1348,11 +1351,22 @@ int begin_new_exec(struct linux_binprm * bprm) > >> * detecting a concurrent rename and just want a term= inated name. > >> */ > >> rcu_read_lock(); > >> - __set_task_comm(me, smp_load_acquire(&bprm->file->f_pa= th.dentry->d_name.name), > >> - true); > >> + fmt =3D smp_load_acquire(&bprm->file->f_path.dentry->d= _name.name); > >> + name =3D kvasprintf(GFP_KERNEL, fmt, args); > >> + if (!name) > >> + return -ENOMEM; > >> + > >> + me->full_name =3D name; > >> + __set_task_comm(me, fmt, true); > >> rcu_read_unlock(); > >> } else { > >> - __set_task_comm(me, kbasename(bprm->filename), true); > >> + fmt =3D kbasename(bprm->filename); > >> + name =3D kvasprintf(GFP_KERNEL, fmt, args); > >> + if (!name) > >> + return -ENOMEM; > >> + > >> + me->full_name =3D name; > >> + __set_task_comm(me, fmt, true); > >> } > >> > >> /* An exec changes our domain. We are no longer part of the t= hread > >> @@ -1399,6 +1413,7 @@ int begin_new_exec(struct linux_binprm * bprm) > >> return 0; > >> > >> out_unlock: > >> + kfree(me->full_name); > >> up_write(&me->signal->exec_update_lock); > >> if (!bprm->cred) > >> mutex_unlock(&me->signal->cred_guard_mutex); > >> diff --git a/include/linux/sched.h b/include/linux/sched.h > >> index 56ddeb37b5cd..053b52606652 100644 > >> --- a/include/linux/sched.h > >> +++ b/include/linux/sched.h > >> @@ -1166,6 +1166,9 @@ struct task_struct { > >> */ > >> char comm[TASK_COMM_LEN]; > >> > >> + /* To store the full name if task comm is truncated. */ > >> + char *full_name; > >> + > > Adding another field to store the task name isn=E2=80=99t ideal. What a= bout > > combining them into a single field, as Linus suggested [0]? > > > > [0]. https://lore.kernel.org/all/CAHk-=3DwjAmmHUg6vho1KjzQi2=3DpsR30+Co= gFd4aXrThr2gsiS4g@mail.gmail.com/ > > > > Thanks for sharing Linus's suggestion. I went through the suggested > changes in the related threads and came up with the following set of poin= ts: > > 1. struct task_struct would contain both 'comm' and 'full_name', Correct. > 2. Remove the task_lock() inside __get_task_comm(), This has been implemented in the patch series titled "Improve the copy of task comm". For details, please refer to: https://lore.kernel.org/linux-mm/20240828030321.20688-1-laoar.shao@gmail.co= m/. > 3. Users of task->comm will be affected in the following ways: Correct. > (a). Printing with '%s' and tsk->comm would just continue to > work,but will get a longer max string. > (b). For users of memcpy.*->comm\>', we should change 'memcpy()' to > 'copy_comm()' which would look like: > > memcpy(dst, src, TASK_COMM_LEN); > dst[TASK_COMM_LEN-1] =3D 0; > > (c). Users which use "sizeof(->comm)" will continue to get the old va= lue because of the hacky union. Using a separate pointer rather than a union could simplify the implementation. I=E2=80=99m open to introducing a new pointer if you believ= e it=E2=80=99s the better approach. > > Am I missing something here. Please let me know your views. --=20 Regards Yafang