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 BD609C52D7F for ; Mon, 12 Aug 2024 13:21:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58E4F6B008A; Mon, 12 Aug 2024 09:21:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53DBD6B008C; Mon, 12 Aug 2024 09:21:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 405F76B0095; Mon, 12 Aug 2024 09:21:39 -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 1C9C86B008A for ; Mon, 12 Aug 2024 09:21:39 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A5829A4EBC for ; Mon, 12 Aug 2024 13:21:38 +0000 (UTC) X-FDA: 82443655476.20.3C91F38 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by imf22.hostedemail.com (Postfix) with ESMTP id C4BB3C001A for ; Mon, 12 Aug 2024 13:21:35 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Tpy35ozh; spf=pass (imf22.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.210.41 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723468861; 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=ntaXkWZopfKg+6j7rnXEQlGZAwKedjmgSjz6FEutgS8=; b=zDL4rteZ/BRFL0YsZsgs6AsiF942AIqUdV1lQ/vo/8CshD6zoFqe1gCqfa7S/KY7KssvK1 iEuOFxGVzCK/ohi1AgMUzMg7clubbyBm59kd4RinbWhCAwz+X3kC/zfGBnjnGzwipP2e0U LrhaATurEXXfZMMIYBc/NTkwhCXWnNg= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Tpy35ozh; spf=pass (imf22.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.210.41 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723468861; a=rsa-sha256; cv=none; b=4TebGGBxnHI6vFhjU0EtISnrdDERVg755pfEsuBvQL2rPVICcuHcGlnS4bLIjTvXuHBVeF /l6mkCdnVkw/BOu5TqTSUzLw3S018KB7Rd5KwHHw8MsXJGxf0R71OVE7KI+ccwgGLSoTaS x/ctjoTzSVjqRh0X6AYbuYIQDNnseuU= Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-7093997dffdso1636376a34.2 for ; Mon, 12 Aug 2024 06:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723468895; x=1724073695; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ntaXkWZopfKg+6j7rnXEQlGZAwKedjmgSjz6FEutgS8=; b=Tpy35ozhdT39YgZey2SGRNwiOydXFcte3Ql8vn+5OISg+cmMPc3eJ/J15DdLYhhsKw wku2J9DdwlCinQYPHhJAov35Z/sA5hhk2Gvi2WCYtF5eRQ5wIrL+g8egNmimBfo91FlO 1xILygUai9AN4tAzsDlamWm3dBcdxmn+M0dFRSmT4MIVPJ2aiJxkoEC4kApvv9nrM7gA VhXA2jOkhexs5uBirrHeLBtNGtP5KOUd8jf9iTmaeZbPGa3fBGM5U/DgmXJo9RMMDXxH Uua8BFdGgXkQLo4hnR9s+eftqAGJjZbg8985o0abCGr4/YDjauSODxQKOvW26MKy2UDd KNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723468895; x=1724073695; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ntaXkWZopfKg+6j7rnXEQlGZAwKedjmgSjz6FEutgS8=; b=CwD4pJwb1PFZO8dikxDJxlPYXZoyELsS2qC0j3dRuWwLgVpeTArjMOZXgHFF7qCT4E LF4xiPMynXjyNgOUoGfEcosNbSub+6/Jo44m4o6xrw5W/spZfk0slppCKMQKketnAFGf PXPvj2R1TRunZGnyCE54rnrPN5yO9lZbikUkGcEtyTZYY7MpbWvcpGGNZNwQhbWtM7c5 b+8AUFn00xvrsbpdHYF/kl1Xy7FCyp2SBcK+5CO4QRyV2W0Al3XOo3I5HuA3s38ZLe+G ucOeT1LZvCvp5mfD40aSrD1ZyOryLNmn/aDTCYuNNLi8jCRjhHGqMCo7t/fdxamB9pnX TuKg== X-Forwarded-Encrypted: i=1; AJvYcCVXAGtIaVVDS/yExgeBz7utnMdwKFOakxItCFyRZ/8i3Fi3R5XWD/D8PTHI3+B/kWUTlClHZ1B31m7ex1KJnPsEHwI= X-Gm-Message-State: AOJu0YwJnqmNdyNoSKZTLXkVSfzdrJrFMLXp55bAxkYjCIZYXvaElehZ VlylArMKrguiWU6o8ADAoWX8TqdlrSU7JUcWZv7KO6YEFW5xo79xPfKihqgIepr9zj47rphAVuV SPRWRgZhRed+voQryQVGhfI5FXio= X-Google-Smtp-Source: AGHT+IGVQve+llYsp0AugSRGeMMoIczqwy8oRpZMYGNh2sJDxIw1ZBHkds1sjMf3hXZlB+uLcjMVRoLPG20nTXUm0IM= X-Received: by 2002:a05:6830:34a6:b0:703:651b:382f with SMTP id 46e09a7af769-70c9387ae3fmr240831a34.3.1723468894738; Mon, 12 Aug 2024 06:21:34 -0700 (PDT) MIME-Version: 1.0 References: <20240812022933.69850-1-laoar.shao@gmail.com> <20240812022933.69850-2-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Mon, 12 Aug 2024 21:20:57 +0800 Message-ID: Subject: Re: [PATCH v6 1/9] Get rid of __get_task_comm() To: Alejandro Colomar Cc: akpm@linux-foundation.org, torvalds@linux-foundation.org, ebiederm@xmission.com, alexei.starovoitov@gmail.com, rostedt@goodmis.org, catalin.marinas@arm.com, penguin-kernel@i-love.sakura.ne.jp, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, audit@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, bpf@vger.kernel.org, netdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Alexander Viro , Christian Brauner , Jan Kara , Kees Cook , Matus Jokay , "Serge E. Hallyn" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: C4BB3C001A X-Stat-Signature: 1ujuhrfj5ot8gqhtywbr45z8tz9tes8a X-HE-Tag: 1723468895-245377 X-HE-Meta: U2FsdGVkX19wLm0ghEQzxAK3Ji9Aah8WlBEpY7THsr3/wMGUKiurd/AigxHCDTfHv8J1URE4Cs9+JA4cLdNDhc7Z4sM9hLTQlUZWAT1JDNqdKKdgcXLesPId01wC8ln4hUef5dOPFp3NiRDrkYZJskQt/2J0bxDQZ2gsIGbq9AUJc8J2wihh265pLRAOVPXx6UAdQ5IkRPjOVVZ2l9PP7TejtecqTy9dr3Mx7nP/dc1579ohoQjMANnRrwuEYeWgOqIwA7+StXfMm5TE1lGBV7OL2wsB2cs2MtLuzaQbnJzacU3k4aXpY7Q0LxjxbkOSW495njDup25pKfEAAjQ+sa5WDL9j6FXPgPypizbrigG0bE0F5nktkSoZ3Lfqd8JBhXDaPLXk7PB9N0PEAvwUq1mJ64IH82jBNsMJ5fSsB8csD8MauZQ5ERZDmLwCNvpnVKv16CpCsQLYwRy2a3UX+pTy5owL7TS0NSednAczzFYoSgBHI0jCOtY5xx8bI4nOh/kaq/ZsZPFJ2CURsEhtIjHD0ald1WXB/0/0Xc6iqxIjyCr8lt1cR/OYd47NTkvx4jExOw2mSd3NrChH8OpMnnD5RauOzmPXUWdS5e0vcdaM7Gll1EV+ioG86s7Yw8jmmBfxf826/7GfFJqiyL4rQXUbQovYGJbe1P8qtp7Ch1hYTtyW/Zos5VUuCb2K4FqOR03IUcI52iV/3hRLO4bSpD88kp2/E90q3jvLahnIb2R67REjZT25RTJnUIuB+gqVbTrMwOTv3PQKgZc5oNdNwxGt7hSTfUpyZvOSbdzEhIxFr6aNmcPBIMTpqaibgTvhzhmDVC1Z7zCEPuGKWEVduu10qoLvOlJPpSw/AZVg32009Nv771aC4Y9K0Y/HQtqcDWky6rhBYCXY8b7ofzUI0RjrKi6ddpUdTJj3JKshc2w7qswxgV0DZdnGlMc8mr7cBipwZG76wsV3RZT8ZJT 0XHpJ2RI mzYEUftDT/WcEtBWAQpIDl98clLphuUKyFcNUCeGYR5LH4VidD4Ul3oVuILzDDoCTbbJ5O4oob7StqQHsUq98V+tZAnn7F8NhTNJ4EGdljIDHdOWmh1JsOm/n/I7q/xkL7yCUPByckTOypHvLuYDd37Uy6se8VM/o/yg0k1zlOh7vwMzawSHES009+NOO4oeYl4+C9vIy0FKrgZCfwsKBfqDWTGuNJLOfw1P+N2MR12tnFNxgYt1m4Kwyw8oBbO6qXqgWesHkOACKFda2f1YV1Vic2oF3wUiApp+5LKQYA70qel3aL1YqxNrjGLeDnldmprhpA/qxg+iLsbf98PL0cy1HoItsizxSABRvSeHVBmxqw3lUrmco9dSP2u2EXI0FFZSESvzumU3CiOb4uy5usAyDkT+lVRs3vcJ3cXGVgotgRAsm+TOU8GufFmiIFaysxXhdbzwyD14kf38IR1FSjlxUFnfMdsmaX/EWaJ3IP0eteoAIw/Z8t3PLEXgR8g4zqhRaDwr44TXreH8p3tqeHcqex4RGdiJBj3IMcTxhXu/diTIjChAZhb3spBQKsGuaEehgM7V31NwyPvMEAJZyMAO5SRbpf/tHk+fZtfFJbXbMPRgo5ax0eYuUstpWy/tNCFR8APvzFXLGIH3JkL3K6AnAKb/3RC38aJZud5UJ2HfTyFMdcdO5ZRPq0yOSsdNZ7fBPZ2se6lPHoZm+WVRBOwV/DqVA7NMA6BbNicwjr6RgWgrwM2HerAN2POf4kgwA6P1RMQB8640QJl4Pr6UQH+S5g9CijbUcYQ+O 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: On Mon, Aug 12, 2024 at 4:05=E2=80=AFPM Alejandro Colomar = wrote: > > Hi Yafang, > > On Mon, Aug 12, 2024 at 10:29:25AM GMT, Yafang Shao wrote: > > We want to eliminate the use of __get_task_comm() for the following > > reasons: > > > > - The task_lock() is unnecessary > > Quoted from Linus [0]: > > : Since user space can randomly change their names anyway, using lock= ing > > : was always wrong for readers (for writers it probably does make sen= se > > : to have some lock - although practically speaking nobody cares ther= e > > : either, but at least for a writer some kind of race could have > > : long-term mixed results > > > > - The BUILD_BUG_ON() doesn't add any value > > The only requirement is to ensure that the destination buffer is a va= lid > > array. > > > > - Zeroing is not necessary in current use cases > > To avoid confusion, we should remove it. Moreover, not zeroing could > > potentially make it easier to uncover bugs. If the caller needs a > > zero-padded task name, it should be explicitly handled at the call si= te. > > > > Suggested-by: Linus Torvalds > > Link: https://lore.kernel.org/all/CAHk-=3DwivfrF0_zvf+oj6=3D=3DSh=3D-np= JooP8chLPEfaFV0oNYTTBA@mail.gmail.com [0] > > Link: https://lore.kernel.org/all/CAHk-=3DwhWtUC-AjmGJveAETKOMeMFSTwKwu= 99v7+b6AyHMmaDFA@mail.gmail.com/ > > Suggested-by: Alejandro Colomar > > Link: https://lore.kernel.org/all/2jxak5v6dfxlpbxhpm3ey7oup4g2lnr3ueurf= bosf5wdo65dk4@srb3hsk72zwq > > Signed-off-by: Yafang Shao > > Cc: Alexander Viro > > Cc: Christian Brauner > > Cc: Jan Kara > > Cc: Eric Biederman > > Cc: Kees Cook > > Cc: Alexei Starovoitov > > Cc: Matus Jokay > > Cc: Alejandro Colomar > > Cc: "Serge E. Hallyn" > > --- > > fs/exec.c | 10 ---------- > > fs/proc/array.c | 2 +- > > include/linux/sched.h | 31 +++++++++++++++++++++++++------ > > kernel/kthread.c | 2 +- > > 4 files changed, 27 insertions(+), 18 deletions(-) > > > > diff --git a/fs/exec.c b/fs/exec.c > > index a47d0e4c54f6..2e468ddd203a 100644 > > --- a/fs/exec.c > > +++ b/fs/exec.c > > @@ -1264,16 +1264,6 @@ static int unshare_sighand(struct task_struct *m= e) > > return 0; > > } > > > > -char *__get_task_comm(char *buf, size_t buf_size, struct task_struct *= tsk) > > -{ > > - task_lock(tsk); > > - /* Always NUL terminated and zero-padded */ > > - strscpy_pad(buf, tsk->comm, buf_size); > > This comment is correct (see other comments below). > > (Except that pedantically, I'd write it as NUL-terminated with a hyphen, > just like zero-padded.) > > > - task_unlock(tsk); > > - return buf; > > -} > > -EXPORT_SYMBOL_GPL(__get_task_comm); > > - > > /* > > * These functions flushes out all traces of the currently running exe= cutable > > * so that a new one can be started > > diff --git a/fs/proc/array.c b/fs/proc/array.c > > index 34a47fb0c57f..55ed3510d2bb 100644 > > --- a/fs/proc/array.c > > +++ b/fs/proc/array.c > > @@ -109,7 +109,7 @@ void proc_task_name(struct seq_file *m, struct task= _struct *p, bool escape) > > else if (p->flags & PF_KTHREAD) > > get_kthread_comm(tcomm, sizeof(tcomm), p); > > else > > - __get_task_comm(tcomm, sizeof(tcomm), p); > > + get_task_comm(tcomm, p); > > LGTM. (This would have been good even if not removing the helper.) > > > > > if (escape) > > seq_escape_str(m, tcomm, ESCAPE_SPACE | ESCAPE_SPECIAL, "= \n\\"); > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > index 33dd8d9d2b85..e0e26edbda61 100644 > > --- a/include/linux/sched.h > > +++ b/include/linux/sched.h > > @@ -1096,9 +1096,11 @@ struct task_struct { > > /* > > * executable name, excluding path. > > * > > - * - normally initialized setup_new_exec() > > - * - access it with [gs]et_task_comm() > > - * - lock it with task_lock() > > + * - normally initialized begin_new_exec() > > + * - set it with set_task_comm() > > + * - strscpy_pad() to ensure it is always NUL-terminated > > The comment above is inmprecise. > It should say either > "strscpy() to ensure it is always NUL-terminated", or > "strscpy_pad() to ensure it is NUL-terminated and zero-padded". will change it. > > > + * - task_lock() to ensure the operation is atomic and the name= is > > + * fully updated. > > */ > > char comm[TASK_COMM_LEN]; > > > > @@ -1912,10 +1914,27 @@ static inline void set_task_comm(struct task_st= ruct *tsk, const char *from) > > __set_task_comm(tsk, from, false); > > } > > > > -extern char *__get_task_comm(char *to, size_t len, struct task_struct = *tsk); > > +/* > > + * - Why not use task_lock()? > > + * User space can randomly change their names anyway, so locking for= readers > > + * doesn't make sense. For writers, locking is probably necessary, a= s a race > > + * condition could lead to long-term mixed results. > > + * The strscpy_pad() in __set_task_comm() can ensure that the task c= omm is > > + * always NUL-terminated. > > This comment has the same imprecission that I noted above. will change it. > > > Therefore the race condition between reader and > > + * writer is not an issue. > > + * > > + * - Why not use strscpy_pad()? > > + * While strscpy_pad() prevents writing garbage past the NUL termina= tor, which > > + * is useful when using the task name as a key in a hash map, most u= se cases > > + * don't require this. Zero-padding might confuse users if it=E2=80= =99s unnecessary, > > + * and not zeroing might even make it easier to expose bugs. If you = need a > > + * zero-padded task name, please handle that explicitly at the call = site. > > + * > > + * - ARRAY_SIZE() can help ensure that @buf is indeed an array. > > + */ > > #define get_task_comm(buf, tsk) ({ \ > > - BUILD_BUG_ON(sizeof(buf) !=3D TASK_COMM_LEN); \ > > - __get_task_comm(buf, sizeof(buf), tsk); \ > > + strscpy(buf, (tsk)->comm, ARRAY_SIZE(buf)); \ > > + buf; \ > > }) > > > > #ifdef CONFIG_SMP > > diff --git a/kernel/kthread.c b/kernel/kthread.c > > index f7be976ff88a..7d001d033cf9 100644 > > --- a/kernel/kthread.c > > +++ b/kernel/kthread.c > > @@ -101,7 +101,7 @@ void get_kthread_comm(char *buf, size_t buf_size, s= truct task_struct *tsk) > > struct kthread *kthread =3D to_kthread(tsk); > > > > if (!kthread || !kthread->full_name) { > > - __get_task_comm(buf, buf_size, tsk); > > + strscpy(buf, tsk->comm, buf_size); > > return; > > } > > Other than that, LGTM. Thanks for your review. --=20 Regards Yafang