Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3570170pxb; Fri, 5 Nov 2021 18:37:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZv0QBqmt8XB5kx0xXkUn3Ft2Hd2FCJ3qT478M7S7YOdHl1jR4Ye0CgoPHOFEJiw7aFRQL X-Received: by 2002:a5d:96cc:: with SMTP id r12mr2165836iol.33.1636162678664; Fri, 05 Nov 2021 18:37:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636162678; cv=none; d=google.com; s=arc-20160816; b=fdrVF0j6R/c65fXO/f2dZVoh5pc4DDFGJJKCHvmCqx7Db8bEypDNvThZzEe7zjFvZl 0JUIYIcQzfEmIPpZQcxlUB5G3/0zirmHBH82i+PvOo95kATcY2Nz6PHEbbVK6hQh/8pW aioyjG5HEmrOqUfwzhrHCuKidPff7IiP8MNlDiwbQau1rG9p6b6pyf2LH2FOA/S6PK1b /F9H2TN+Oida7eEIMrY9bbhLl3f0vg6Fu1IPfkVLSpH0MHs/DHz3fjxFkIMTY7zEeze/ TGVBNsX/q1YlqM3c8tif/aAqjFXG4FansygfQwfcf/WSoVv4ruFR1a1xF2OOZELn6ITF 4xWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Mys356gNBn2wzAOiXzBTt2VgM5vKVGWiemPaK5C/7XM=; b=HjyykZ9gM+4GYG2dmcjqeoW0j1sx88BoX93nV0bnoF80qcKKgrhdZmkl4lK/n0+klu UbiBN4Nsk8Yt6cgIqcMGXSs3OsYnHJCxgksyNC9cmLy+GAAqqFR4V+EAKisikTu2EQ/n OUFh9cakktp9WZM002uW1P1q+Rb/abUfwSEaQbvVs+DIIn5+3xIzB89zxzijrONKiKNb g4yXiM2XeNnWRAAXUnD2kFQYZWzlDyYkYBrinJyroQCOJzCg3l5KWEdbrQdrpyGWJsvT o6L8Jc8tkMjYGkD/TxeOHJCLI50rh37QmNzrx9wP1P2z6WsqVfbEHZy/2OZ8jS2FoVRF mUhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rere.qmqm.pl header.s=1 header.b=hhhHpB7Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=rere.qmqm.pl Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n1si1218182jav.91.2021.11.05.18.37.46; Fri, 05 Nov 2021 18:37:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@rere.qmqm.pl header.s=1 header.b=hhhHpB7Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=rere.qmqm.pl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233425AbhKFAAA (ORCPT + 99 others); Fri, 5 Nov 2021 20:00:00 -0400 Received: from rere.qmqm.pl ([91.227.64.183]:20332 "EHLO rere.qmqm.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233311AbhKEX75 (ORCPT ); Fri, 5 Nov 2021 19:59:57 -0400 Received: from remote.user (localhost [127.0.0.1]) by rere.qmqm.pl (Postfix) with ESMTPSA id 4HmHVb6HGFzBs; Sat, 6 Nov 2021 00:57:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rere.qmqm.pl; s=1; t=1636156635; bh=m5pndQqsZAfsS+FW1lbAnLViWscX+7vW/HS+H4mYBKg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hhhHpB7ZS4HG39gN9VN9s41HVGTMpArfwk+CIFrRRUhAAn2nVMgZajsgWsAEvJ5Uh E5kVQtH50Hw+vS/SQw2R4N2aAeNeaQxjqX7ir5sEPslX0+QLwnK90B76F+LeCC0oAQ PIxCMskP3Gv3nwVt/hQmWgI+O03uONbc4LfkN9p5SDeJJBZ6ZRwwme7leUxbDszrVm dEbpNMH+ZwjXs15naK6R98AzrEPJWYY5dGiGyLyQtkGFN9d/rjaiicUDQ2N/I12qdE 3ePV/0GKFuuOK26dKbitWlt3+bMzUazhaKZ5rx7dILwSez6IuMQDIpnakNB9l+ZBGt /qCnycePN9fPQ== X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at mail Date: Sat, 6 Nov 2021 00:57:06 +0100 From: =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= To: Yafang Shao 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 Subject: Re: [PATCH v7 00/11] extend task comm from 16 to 24 Message-ID: References: <20211101060419.4682-1-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 05, 2021 at 02:34:58PM +0800, Yafang Shao wrote: > On Thu, Nov 4, 2021 at 9:37 AM Micha? Miros?aw 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 trouble > > > 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 extending > > > 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 mostly > > 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 more > > involved than I had time for. > > > > [1] https://rere.qmqm.pl/git/?p=linux;a=commit;h=2c3814268caf2b1fee6d1a0b61fd1730ce135d4a > > 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=linux;a=commit;h=cfd99db9cf911bb4d106889aeba1dfe89b6527d0) > [bluetooth: prepare for bigger > TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=linux;a=commit;h=ba2805f5196865b81cc6fc938ea53af2c7c2c892) > [taskstats: prepare for bigger > TASK_COMM_LEN](https://rere.qmqm.pl/git/?p=linux;a=commit;h=4d29bfedc57b36607915a0171f4864ec504908ca) > [mm: make TASK_COMM_LEN > configurable](https://rere.qmqm.pl/git/?p=linux;a=commit;h=362acc35582445174589184c738c4d86ec7d174b) > > 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. > 2. A fix > Below patch: > [procfs: signal /proc/PID/comm write > truncation](https://rere.qmqm.pl/git/?p=linux;a=commit;h=d72027388d4d95db5438a7a574e0a03ae4b5d6d7) > > 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=linux;a=commit;h=2c3814268caf2b1fee6d1a0b61fd1730ce135d4a) > > 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. Best Regards Micha??Miros?aw