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 C304EC433F5 for ; Thu, 25 Nov 2021 14:47:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 519BD6B0078; Thu, 25 Nov 2021 09:47:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C9246B007B; Thu, 25 Nov 2021 09:47:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 343FF6B007D; Thu, 25 Nov 2021 09:47:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 271806B0078 for ; Thu, 25 Nov 2021 09:47:22 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E0B5B184C114F for ; Thu, 25 Nov 2021 14:47:11 +0000 (UTC) X-FDA: 78847730220.27.93F9EF7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id EC716E002100 for ; Thu, 25 Nov 2021 14:47:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637851630; h=from:from: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; bh=r0YfT7b8wVOeig/3+IUDAZI2A/DKcXL2UWIWBuICztQ=; b=EW2b3l50rN7GOR/k2rzAJVkoQtBMSxFmeemYU+VBTAZvvrAu+gbBdnvvFzlOOd1wV9PEz+ TXXBoCWKId+6Ev9vUwigbcC9c1a2sBYRp4jI+q3t8LKXTwwcGFMQFAlFLWIwze0zdSMO9Z 40xisGPBMEvw+UMJVl7rHrcooSCi83o= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-448-R5B_2QbVMga3HxmGJIYJ4w-1; Thu, 25 Nov 2021 09:47:07 -0500 X-MC-Unique: R5B_2QbVMga3HxmGJIYJ4w-1 Received: by mail-wm1-f69.google.com with SMTP id r129-20020a1c4487000000b00333629ed22dso5089574wma.6 for ; Thu, 25 Nov 2021 06:47:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=r0YfT7b8wVOeig/3+IUDAZI2A/DKcXL2UWIWBuICztQ=; b=aTolZnpafS1nLr0GTmjowDS8KJgCzLgGYUjy7r3utO45Ch5CsO4dEiavItOQPvJE0q +1wRPvxrxQawxV4HeaEepkc3h77Dsuno765oh4aQ8149Tg0maWrzi+cptFYH29wxdsOf C/HIF5h3pQgcpjmQlqBA1o4fWT1lHz3XUad/TloISyttSP1dWjRpSHwWFTLjpvspmuRl hoLqoquqVcGf9N3RR1I6C5IOm4GHdzh+plVxJKbxiflNC+xN8sopvYf0YlzpZwrP45Uh DjTsti51e17rvSwR4DGtaVp4mS69Ljvfh3Ad7wPi7cLWheHQ18DN0zhJsYS67PTlS56N 6fWA== X-Gm-Message-State: AOAM53131iCkeVLkCU9ldZX2VMubm1mlMPCINbbSn8DsiTAP6Yww76RR Gl2UH37g9R/dHkM78w9/xqirrupZm8korzCRC+oTajZv7+HEdPo902MyH/GdTHpxngI5fup5UfB TH80FfZCgOD4= X-Received: by 2002:a7b:c763:: with SMTP id x3mr7962995wmk.31.1637851626068; Thu, 25 Nov 2021 06:47:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJwWw5wfsPq7LRSM9hRLSA4XFFZZK0hqXGaWJlTIAPX0085VuaF1bzZGOZEdl44rHrNuL6HnNg== X-Received: by 2002:a7b:c763:: with SMTP id x3mr7962942wmk.31.1637851625817; Thu, 25 Nov 2021 06:47:05 -0800 (PST) Received: from [192.168.3.132] (p5b0c679e.dip0.t-ipconnect.de. [91.12.103.158]) by smtp.gmail.com with ESMTPSA id be3sm9930088wmb.1.2021.11.25.06.47.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Nov 2021 06:47:05 -0800 (PST) Message-ID: <68615778-08cc-6216-1def-764dff112a72@redhat.com> Date: Thu, 25 Nov 2021 15:47:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v2] kthread: dynamically allocate memory to store kthread's full name To: Petr Mladek Cc: Yafang Shao , akpm@linux-foundation.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, oliver.sang@intel.com, lkp@intel.com, Steven Rostedt , Mathieu Desnoyers , Arnaldo Carvalho de Melo , Alexei Starovoitov , Andrii Nakryiko , Michal Miroslaw , Peter Zijlstra , Matthew Wilcox , Al Viro , Kees Cook References: <20211120112850.46047-1-laoar.shao@gmail.com> <435fab0b-d345-3698-79af-ff858181666a@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: EC716E002100 X-Stat-Signature: deu6xsk4cwk5d5hbcx3mdm68wi1m7jec Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=EW2b3l50; spf=none (imf30.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1637851623-584077 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 25.11.21 15:46, Petr Mladek wrote: > On Thu 2021-11-25 10:36:49, David Hildenbrand wrote: >> On 20.11.21 12:28, Yafang Shao wrote: >>> When I was implementing a new per-cpu kthread cfs_migration, I found the >>> comm of it "cfs_migration/%u" is truncated due to the limitation of >>> TASK_COMM_LEN. For example, the comm of the percpu thread on CPU10~19 are >>> all with the same name "cfs_migration/1", which will confuse the user. This >>> issue is not critical, because we can get the corresponding CPU from the >>> task's Cpus_allowed. But for kthreads correspoinding to other hardware >>> devices, it is not easy to get the detailed device info from task comm, >>> for example, >>> >>> jbd2/nvme0n1p2- >>> xfs-reclaim/sdf >>> >>> Currently there are so many truncated kthreads: >>> >>> rcu_tasks_kthre >>> rcu_tasks_rude_ >>> rcu_tasks_trace >>> poll_mpt3sas0_s >>> ext4-rsv-conver >>> xfs-reclaim/sd{a, b, c, ...} >>> xfs-blockgc/sd{a, b, c, ...} >>> xfs-inodegc/sd{a, b, c, ...} >>> audit_send_repl >>> ecryptfs-kthrea >>> vfio-irqfd-clea >>> jbd2/nvme0n1p2- >>> ... >>> >>> We can shorten these names to work around this problem, but it may be >>> not applied to all of the truncated kthreads. Take 'jbd2/nvme0n1p2-' for >>> example, it is a nice name, and it is not a good idea to shorten it. >>> >>> One possible way to fix this issue is extending the task comm size, but >>> as task->comm is used in lots of places, that may cause some potential >>> buffer overflows. Another more conservative approach is introducing a new >>> pointer to store kthread's full name if it is truncated, which won't >>> introduce too much overhead as it is in the non-critical path. Finally we >>> make a dicision to use the second approach. See also the discussions in >>> this thread: >>> https://lore.kernel.org/lkml/20211101060419.4682-1-laoar.shao@gmail.com/ >>> >>> After this change, the full name of these truncated kthreads will be >>> displayed via /proc/[pid]/comm: >>> >>> rcu_tasks_kthread >>> rcu_tasks_rude_kthread >>> rcu_tasks_trace_kthread >>> poll_mpt3sas0_statu >>> ext4-rsv-conversion >>> xfs-reclaim/sdf1 >>> xfs-blockgc/sdf1 >>> xfs-inodegc/sdf1 >>> audit_send_reply >>> ecryptfs-kthread >>> vfio-irqfd-cleanup >>> jbd2/nvme0n1p2-8 >> >> I do wonder if that could break some user space that assumes these names >> have maximum length .. > > There is high chance that we will be on the safe side. Workqueue > kthreads already provided longer names. They are even dynamic > because the currently handled workqueue name is part of the name, > see wq_worker_comm(). Great, thanks! -- Thanks, David / dhildenb