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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F076BC433F5 for ; Sat, 6 Nov 2021 09:13:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7BAB66113A for ; Sat, 6 Nov 2021 09:13:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7BAB66113A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9246E94000D; Sat, 6 Nov 2021 05:13:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D55494000A; Sat, 6 Nov 2021 05:13:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C2C794000D; Sat, 6 Nov 2021 05:13:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 6E4E694000A for ; Sat, 6 Nov 2021 05:13:04 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2482C82499A8 for ; Sat, 6 Nov 2021 09:13:04 +0000 (UTC) X-FDA: 78777941088.08.3B4D8EE Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf01.hostedemail.com (Postfix) with ESMTP id B89F0508E25E for ; Sat, 6 Nov 2021 09:12:49 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id bi29so10984425qkb.5 for ; Sat, 06 Nov 2021 02:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PX63qJThybc8qmxgHYUMYlSyCq1NFMGIDZAgv7Xx9LM=; b=PCHCxhfQGKHkgBbVj/JAGlmlsEBIiLTckTLku56k8nvSzpt8kyEsjRRcmQ4m6iR4HX JATH+60zm+4MXfoSHnj6dC/BbNPVEwW/Ij1ErOTSiHbhSPYS0x5gez0wITXMVmG+8Se7 dJ7YJiPmnxQB8biUc8cmmQvAev0Myq/+QqfRsJFGT6UMruKUFLfhoTQS+9C13YrKhPJS BvkwfuaaI4EndhzKlXMDowViJk/szsiW2q5mUEZHJrjEcnG3Gy76d7BbwO2Eapw4RPJt ZOYLVijLAdocPJKqnkxM6PU9CNjljiXI9dNg0xikdeTA0jp7yjIrfzIQCTDtWEMh57P3 Jtpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PX63qJThybc8qmxgHYUMYlSyCq1NFMGIDZAgv7Xx9LM=; b=p324eYgIskbwtJeunc2JuoKQGnYq+Ot0xcGzaswuhT2KG0BqQm1J1dEvj/AU8+N30i c8Pw3UVGD79ppc23jsdZbn5WyxRQUZ4HWmu9XZpk6BoccSnPZKKKIM92nSN6cNz1bxad CmfRAYbXH2X8m9QNQ4sR4wpGdhk6QETh8Z9cwXXf36LWy5NDrNOO4uzMX6HFAaVjv8V0 v6eU504yxxordBrQ7v2cM26UiEoj7+SlYFeWXRb+rdXciWyhroR6jPyzGcdfGsYIBuhy eML+htQNSP2r4s21Ls0v3D0PLj4rcS7Fm64iTzuD3rjmtAx6BByzxeUalpBVhDoWHumu gWBA== X-Gm-Message-State: AOAM533fr5LDsWEt0Pfa4pv+FmY2XKCIBqCPG0djn9JxRtDfuAKlapMr WFd8xgdPxM7yaDzWOsIKZc4d2xcaY28Ih+eeav8= X-Google-Smtp-Source: ABdhPJzcgK4H7AdugIlTueY2VSiyaBGl6vbyH+oEMhigN1Ho/LAfp5M9vcc9nP1GB5Kg/0hVtXWP6INtd1Plta4Iqpc= X-Received: by 2002:a37:9a42:: with SMTP id c63mr2527573qke.216.1636189981026; Sat, 06 Nov 2021 02:13:01 -0700 (PDT) MIME-Version: 1.0 References: <20211101060419.4682-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sat, 6 Nov 2021 17:12:24 +0800 Message-ID: Subject: Re: [PATCH v7 00/11] extend task comm from 16 to 24 To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Cc: Andrew Morton , Kees Cook , Steven Rostedt , Mathieu Desnoyers , Arnaldo Carvalho de Melo , Petr Mladek , Peter Zijlstra , Al Viro , Valentin Schneider , Qiang Zhang , robdclark , christian , Dietmar Eggemann , Ingo Molnar , Juri Lelli , Vincent Guittot , David Miller , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , dennis.dalessandro@cornelisnetworks.com, mike.marciniszyn@cornelisnetworks.com, dledford@redhat.com, jgg@ziepe.ca, linux-rdma@vger.kernel.org, netdev , bpf , "linux-perf-use." , linux-fsdevel@vger.kernel.org, Linux MM , LKML , kernel test robot , kbuild test robot Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B89F0508E25E X-Stat-Signature: jgc4ueoieb1c8wb4etnw89np16jdiiie Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=PCHCxhfQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.222.177 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com X-HE-Tag: 1636189969-499044 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: On Sat, Nov 6, 2021 at 7:57 AM Micha=C5=82 Miros=C5=82aw wrote: > > On Fri, Nov 05, 2021 at 02:34:58PM +0800, Yafang Shao wrote: > > On Thu, Nov 4, 2021 at 9:37 AM Micha=C5=82 Miros=C5=82aw wrote: > > > > > > On Mon, Nov 01, 2021 at 06:04:08AM +0000, Yafang Shao wrote: > > > > There're many truncated kthreads in the kernel, which may make trou= ble > > > > for the user, for example, the user can't get detailed device > > > > information from the task comm. > > > > > > > > This patchset tries to improve this problem fundamentally by extend= ing > > > > the task comm size from 16 to 24, which is a very simple way. > > > [...] > > > > > > Hi, > > > > > > I've tried something like this a few years back. My attempt got mostl= y > > > lost in the mailing lists, but I'm still carrying the patches in my > > > tree [1]. My target was userspace thread names, and it turned out mor= e > > > involved than I had time for. > > > > > > [1] https://rere.qmqm.pl/git/?p=3Dlinux;a=3Dcommit;h=3D2c3814268caf2b= 1fee6d1a0b61fd1730ce135d4a > > > and its parents > > > > > > > Hi Michal, > > > > Thanks for the information. > > > > I have looked through your patches. It seems to contain six patches > > now and can be divided into three parts per my understanding. > > > > 1. extend task comm len > > This parts contains below 4 patches: > > [prctl: prepare for bigger > > TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=3Dlinux;a=3Dcommit;h=3Dcfd99= db9cf911bb4d106889aeba1dfe89b6527d0) > > [bluetooth: prepare for bigger > > TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=3Dlinux;a=3Dcommit;h=3Dba280= 5f5196865b81cc6fc938ea53af2c7c2c892) > > [taskstats: prepare for bigger > > TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=3Dlinux;a=3Dcommit;h=3D4d29b= fedc57b36607915a0171f4864ec504908ca) > > [mm: make TASK_COMM_LEN > > configurable](https://rere.qmqm.pl/git/?p=3Dlinux;a=3Dcommit;h=3D362acc= 35582445174589184c738c4d86ec7d174b) > > > > What kind of userspace issues makes you extend the task comm length ? > > Why not just use /proc/[pid]/cmdline ? > > This was to enable longer thread names (as set by pthread_setname_np()). > Currently its 16 bytes, and that's too short for e.g. Chrome's or Firefox= 'es > threads. I believe that FreeBSD has 32-byte limit and so I expect that > major portable code is already prepared for bigger thread names. > The comm len in FreeBSD is (19 + 1) bytes[1], but that is still larger than Linux :) The task comm is short for many applications, that is why cmdline is introduced per my understanding, but pthread_{set, get}name_np() is reading/writing the comm or via prctl(2) rather than reading/writing the cmdline... Is the truncated Chrome or Firefox thread comm really harmful or is extending the task comm just for portable? Could you pls show me some examples if the short comm is really harmful? Per my understanding, if the short comm is harmful to applications then it is worth extending it. But if it is only for portable code, it may not be worth extending it. [1]. https://github.com/freebsd/freebsd-src/blob/main/sys/sys/param.h#L126 > > 2. A fix > > Below patch: > > [procfs: signal /proc/PID/comm write > > truncation](https://rere.qmqm.pl/git/?p=3Dlinux;a=3Dcommit;h=3Dd7202738= 8d4d95db5438a7a574e0a03ae4b5d6d7) > > > > It seems this patch is incomplete ? I don't know what it means to do. > > Currently writes to /proc/PID/comm are silently truncated. This patch > makes the write() call return the actual number of bytes actually written > and on subsequent calls return -ENOSPC. glibc checks the length in > pthread_setname_np() before write(), so the change is not currently > relevant for it. I don't know/remember what other runtimes do, though. > > > 3. A feature provided for pthread_getname_np > > Below patch: > > [procfs: lseek(/proc/PID/comm, 0, > > SEEK_END)](https://rere.qmqm.pl/git/?p=3Dlinux;a=3Dcommit;h=3D2c3814268= caf2b1fee6d1a0b61fd1730ce135d4a) > > > > It seems this patch is useful. With this patch the userspace can > > directly get the TASK_COMM_LEN through the API. > > This one I'm not really fond of because it abuses lseek() in that it > doesn't move the write pointer. But in case of /proc files this normally > would return EINVAL anyway. > Another possible way is introducing a new PR_GET_COMM_LEN for prctl(2), but I'm not sure if it is worth it. --=20 Thanks Yafang