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 F1AECC54ED0 for ; Fri, 23 May 2025 12:32:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42E1E6B00CD; Fri, 23 May 2025 08:32:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DE996B00CE; Fri, 23 May 2025 08:32:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A60D6B00CF; Fri, 23 May 2025 08:32:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 08AEB6B00CD for ; Fri, 23 May 2025 08:32:07 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B008E1A02C2 for ; Fri, 23 May 2025 12:32:06 +0000 (UTC) X-FDA: 83474109852.28.2E76688 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) by imf26.hostedemail.com (Postfix) with ESMTP id B8645140013 for ; Fri, 23 May 2025 12:32:04 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=dtTyykSV; dmarc=pass (policy=none) header.from=igalia.com; spf=pass (imf26.hostedemail.com: domain of bhsharma@igalia.com designates 213.97.179.56 as permitted sender) smtp.mailfrom=bhsharma@igalia.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748003524; 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=yO0EwDZrf4fd992J3B8iCK71Ip2ga1Ayg9UxqoNl3Zw=; b=hwLwehGMCFOLEESfoTxLLCJ0q8k9OIp0eQP2myQy9IvYk+JJ3b4dEfVgImJbElbYBNj/GH TLHRohsvz7T8fuEAuk2lnAKQ4/NKKbWz0eqvnuLXEjDgsTVEqCbwe7O6EuvQXTtO2M3yD3 iYO0sX6yeKqTgHDycQg12X+7hWxJmmM= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=igalia.com header.s=20170329 header.b=dtTyykSV; dmarc=pass (policy=none) header.from=igalia.com; spf=pass (imf26.hostedemail.com: domain of bhsharma@igalia.com designates 213.97.179.56 as permitted sender) smtp.mailfrom=bhsharma@igalia.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748003524; a=rsa-sha256; cv=none; b=IBLXIqEHBOoVHckqn9GFJhx8s35z1otJVOYLmsZ9vZyg9rvtwl9XvPpeDKjuy7CpEXwt9c +vayCfsYI6QmIZ8ynriWKseVWBOvlxOtKiOOUPAH7z+kJ9mAyqugkcYL2SbPaI0R7P9Bbf XfpZREb1HzI5o/3E3DRJFMTQb5ka39A= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yO0EwDZrf4fd992J3B8iCK71Ip2ga1Ayg9UxqoNl3Zw=; b=dtTyykSVssYRpd4G7j3B1bGx7I XaQ18MuK8E645S1dcEUB3aD0MCqSWaQrM8s5x4zd7EMH21QPKvZLczSBuupJvoATKwLzkNDz0oKzu zRbXx08nyKMkS4pymGSq4SQkGRV4apCr3ONB78Zr+sphNCIq0b5ob9xUJVBTi4ubC2cBJjSY073Yg TlVq/YRLU9Q8wN57CZXZ59s6qDswZVnBXNVx9kQo/74OSSCd0nasd+9qRZOek6hwqtuzv+2YP6iek fyTrBrCqR79iZ46ueTEXEhkuBrtjifNRI9A58IN0M1VTKXjMtLMZi/CidjNG0DgWI0g/DPPgrACDo Fy4F4v/A==; Received: from [223.233.76.245] (helo=[192.168.1.12]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1uIRZ1-00CB4g-9x; Fri, 23 May 2025 14:31:51 +0200 Message-ID: Date: Fri, 23 May 2025 18:01:41 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v4 3/3] exec: Add support for 64 byte 'tsk->comm_ext' Content-Language: en-US To: Kees Cook , Bhupesh Cc: 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, laoar.shao@gmail.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, 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, linux-trace-kernel@vger.kernel.org References: <20250521062337.53262-1-bhupesh@igalia.com> <20250521062337.53262-4-bhupesh@igalia.com> <202505222041.B639D482FB@keescook> From: Bhupesh Sharma In-Reply-To: <202505222041.B639D482FB@keescook> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B8645140013 X-Stat-Signature: 6nwedqhnzyx3sbd86xe7sacq5pqwaor8 X-Rspam-User: X-HE-Tag: 1748003524-925767 X-HE-Meta: U2FsdGVkX18cZPahZfGkZuC7Iv/iGHDV5uh1AdtJYSk+a3K+xNEtxEVTELljeBuuC5FEli3f8qzo38tx65Y28WLXqb9PBelt4sDNWZFKDffgqdoddE7Rmd4JrPzMHKmpk/ShnTXwLy2+YKIrx6Z5f1QTLjww+j1M3cxy56ZXe4k8kC6KkXX7K3Tv7zJZvs3Xwnht5FOj2bq9f90UXY50IOZw1b6mRprRp1IlsGKZ21VA2ok4/Bs41ECJ5qpNB7oF/mK7VRbIn1fVu3Rw0SSZ54NBRlqZUygqq2LgneZCcVnE5SwUEAn6KD29xsMOn7toKs7rXATZSd3j/IEvI9pcd2+emg74DO9lvmzJzGYWw8nl/haS1EkiUiRj8Nn7PLsnVUarPnuIUHtyh99vuUn6HOo3zkRDA8eg71EL+QQnDHByeQcdUG+vU4Frm/blj6GDbv1SzLNe8/A+ECHx8JS9SzU/N7tKrRj0nqPMGyucj9udkBagiv61d3dBvX2X2uclMX6tenRefFu/R4EcjOXfDCPJMsuObpmxwBqLpBiFyBXRLHRmYYx+SEyn0wd83cOFUZIQuhUeHFcwYVR2ERlclrgCpXu6Z/OEHwRw5nAsHzjAQYRGS6N7B1KrD3ByjFZTyjb48XrBWdbUu7XouBIUxztb5UogwAHHAiIwdUE+d1OXByYlrqjjjdlys9RcL7YGMrqso27UHga5miMLBhoLYlHM7PBEnDIVkvz8nGW/XNOqeH/RhbtqKNva+boffz8dUFdho9XRS81LK/ZOdsufTmgycp/rl/XVB/6gKAoMxR7ameQWOeDpvLHn4Jl2G+lxQuJj1FvCTt9KzeBBXlgq7xe11v9GCA5BU2cU54ldW+3bqonLjaUh1G3HoLc7ixtR1RAeWPxHYM+95TrLGMu84NeJJm7gTTmc6aL1BqjI2Vc2RNna3NKH4mU3G66AT8kEz2Z6VAJ/KR9cVDT9YuU TYL9+T7X zzz0VcbysUuTOYfFI714LprL83CSy1qGLGSnWA7efQuZAAqRzkdQDurPrwsbhC4EfRzR9mT2aBcwfSC+hQZae/BfRT8hVvkDSb/KwexW9yTiga6gz9fZ19YtV1/wkAVyfqlFExqG/aZ39ZC/r2ZB6bcrDK/UPb9VCMHCUPgRUjlYhjAJTmOKAP10GVUqVoJABECDfhtScL7uzxL0SYuePt1orSk3ENY47cm7xzaTPDQ3N9t0yB+VkHLv4WO4O5CEXrXyB1s0DUMMTAarP+Czrvz9/kunqqx58ch29BwiXZKtLAC5W83ckjmI5lQf/85fBHzh2cNZOTrWHUdKgzotAlRPkXrDrkZLX+NlRbuRrZRibe21cfqHxc+idQ86rWSFB4Cxw3nzJlZxn3Z8XpLYMCFXWHxDXbgF/r56D 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: Hi Kees, Thanks for the review. On 5/23/25 9:18 AM, Kees Cook wrote: > On Wed, May 21, 2025 at 11:53:37AM +0530, Bhupesh wrote: >> Historically due to the 16-byte length of TASK_COMM_LEN, the >> users of 'tsk->comm' are restricted to use a fixed-size target >> buffer also of TASK_COMM_LEN for 'memcpy()' like use-cases. >> >> To fix the same, Linus suggested in [1] that we can add the >> following union inside 'task_struct': >> union { >> char comm[TASK_COMM_LEN]; >> char comm_ext[TASK_COMM_EXT_LEN]; >> }; > I remain unconvinced that this is at all safe. With the existing > memcpy() and so many places using %s and task->comm, this feels very > very risky to me. > > Can we just make it separate, instead of a union? Then we don't have to > touch comm at all. I understand your apprehensions, but I think we have covered _almost_ all the existing use-cases as of now: 1. memcpy() users: Handled by [PATCH 2/3] of this series, where we identify existing users using the following search     pattern:        $ git grep 'memcpy.*->comm\>' 2. %s usage: I checked this at multiple places and can confirm that %s usage to print out 'tsk->comm' (as a string), get the longer     new "extended comm". 3. users who do 'sizeof(->comm)' will continue to get the old value because of the union. The problem with having two separate comms: tsk->comm and tsk->ext_comm, instead of a union is two fold: (a). If we keep two separate statically allocated comms: tsk->comm and tsk->ext_comm in struct task_struct, we need to basically keep supporting backward compatibility / ABI via tsk->comm and ask new user-land users to move to tsk->ext_comm. (b). If we keep one statically allocated comm: tsk->comm and one dynamically allocated tsk->ext_comm in struct task_struct, then we have the problem of allocating the tsk->ext_comm which _may_ be in the exec() hot path. I think the discussion between Linus and Yafang (see [1]), was more towards avoiding the approach in 3(a). Also we discussed the 3(b) approach, during the review of v2 of this series, where there was a apprehensions around: adding another field to store the task name and allocating tsk->ext_comm dynamically in the exec() hot path (see [2]). [1]. https://lore.kernel.org/all/CAHk-=wjAmmHUg6vho1KjzQi2=psR30+CogFd4aXrThr2gsiS4g@mail.gmail.com/ [2]. https://lore.kernel.org/lkml/CALOAHbB51b-reG6+ypr43sBJ-QpQhF39r5WPjuEp5rgabgRmoA@mail.gmail.com/ Please let me know your views. Thanks, Bhupesh >> and then modify '__set_task_comm()' to pass 'tsk->comm_ext' >> to the existing users. > We can use set_task_comm() to set both still... >