Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3662879pxb; Mon, 1 Nov 2021 18:21:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLBhbeSglW/GJf0UcJ0TNpyOXGtnzw7v9JnEXvtVieHbvRHkVvi0GEZjjW46bAM0XFsiAW X-Received: by 2002:a05:6638:1383:: with SMTP id w3mr24972611jad.102.1635816088099; Mon, 01 Nov 2021 18:21:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635816088; cv=none; d=google.com; s=arc-20160816; b=e+sGIchjiy64w9MvVTwbHBVo/CCI//C3FMOvh6saOgCo54tyS9m9r8+qW5WBj14JCD sfXT6IuJajLrEaQVSTmGfTPXww8TWEiZigWgkdn7MzayNPnDTBjMNKffobQcJGT1j8d7 o3USkvzXDhEQCMx3SNHoO4jTytbXPL/7ZqGal7W8GciHrh7YvRQ3TaItmkaxrRvo5Grm yoOkjwux9AcbRIijJzbZWvHzXDQi5N7y52TwZA3tcg0D8VVl0CaTPNCOgJLZSJwMcsNj x2CpxFBXEkKxuII3GXHbXWYuk8nnLpAve6RZKmeTgkwesmtQOJzrvSY5nperzszYEvn4 C/Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=GApC/Wk9mYgcjydWkP+YVu6G4fZEpp/F1+wMi72/QgU=; b=z6vvVrpdFYKtl2wfnyMoYPe4/KmjmgwMVqRvbyyGM0PYoQZVRb5ZhCSBNmBHFqwA7q BC8ziUeCga4+zU/wQMyWTgxTh6We4D1ituDgsy0xDYH3nUgH+DQzqf+sBeHQ71ta/pL0 7YtYxRtz1gnrPdHIxU1AUfXH5XHYqs73mavzx4aTg/4ci95yX9bkhcwCHCPV89CFc/fG 1LJOXsCTfK6N+Ayj2hONFuTKGoUWwaALZsP0hh9WAGnXqC250BUNSVs5QnypB4RUg3DN 6pHFkz84+2mokyYrN9vQCb2JHi3Vl92svZi0XJTjDnpgOlLCiULecU78zp4qbMd2Cb5x xr1w== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f13si3843533iow.59.2021.11.01.18.21.14; Mon, 01 Nov 2021 18:21:28 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231419AbhKBBV0 (ORCPT + 99 others); Mon, 1 Nov 2021 21:21:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:53166 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229510AbhKBBVZ (ORCPT ); Mon, 1 Nov 2021 21:21:25 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DF35F61051; Tue, 2 Nov 2021 01:18:47 +0000 (UTC) Date: Mon, 1 Nov 2021 21:18:45 -0400 From: Steven Rostedt To: Yafang Shao Cc: Petr Mladek , Andrew Morton , Kees Cook , Mathieu Desnoyers , Arnaldo Carvalho de Melo , 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: <20211101211845.20ff5b2e@gandalf.local.home> In-Reply-To: References: <20211101060419.4682-1-laoar.shao@gmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Nov 2021 09:09:50 +0800 Yafang Shao wrote: > So if no one against, I will do it in two steps, > > 1. Send the task comm cleanups in a separate patchset named "task comm cleanups" > This patchset includes patch #1, #2, #4, #5, #6, #7 and #9. > Cleaning them up can make it less error prone, and it will be > helpful if we want to extend task comm in the future :) Agreed. > > 2. Keep the current comm[16] as-is and introduce a separate pointer > to store kthread's long name I'm OK with this. Hopefully more would chime in too. > Now we only care about kthread, so we can put the pointer into a > kthread specific struct. > For example in the struct kthread, or in kthread->data (which may > conflict with workqueue). No, add a new field to the structure. "full_name" or something like that. I'm guessing it should be NULL if the name fits in TASK_COMM_LEN and allocated if the name had to be truncated. Do not overload data with this. That will just make things confusing. There's not that many kthreads, where an addition of an 8 byte pointer is going to cause issues. > > And then dynamically allocate a longer name if it is truncated, > for example, > __kthread_create_on_node > len = vsnprintf(name, sizeof(name), namefmt, args); > if (len >= TASK_COMM_LEN) { > /* create a longer name */ And make sure you have it fail the kthread allocation if it fails to allocate. > } > > And then we modify proc_task_name(), so the user can get > kthread's longer name via /proc/[pid]/comm. Agreed. > > And then free the allocated memory when the kthread is destroyed. Correct. Thanks, -- Steve