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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8DA5C433FE for ; Thu, 11 Nov 2021 11:47:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 792246124C for ; Thu, 11 Nov 2021 11:47:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 792246124C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C12E66B0072; Thu, 11 Nov 2021 06:47:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC24F6B0075; Thu, 11 Nov 2021 06:47:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8B496B0087; Thu, 11 Nov 2021 06:47:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id 99D826B0072 for ; Thu, 11 Nov 2021 06:47:38 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 54B6C18503B44 for ; Thu, 11 Nov 2021 11:47:38 +0000 (UTC) X-FDA: 78796474596.14.5B4DC21 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf09.hostedemail.com (Postfix) with ESMTP id B127C3000117 for ; Thu, 11 Nov 2021 11:47:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636631257; 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=3FPfS7kZXFceS9Lgp1RH/lsyVsBLRGLqfS3FoOXYSuE=; b=JUG0zHkr9XKE+vyp2JQ6ZOnO7o1vblP3jalWF4kINFFMYiaplaDm9Z8PxGwLW6pMoGFutK wClQirNVbisXCdAvgSvn5/0BWygrFVn7hTc6h0yMsuV02eUZe+0OWYyMOyWav098hjC4q7 vgY/hnArrBuzrOh7X+lXS0JHzwP2DMc= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-53-NH6UDy2_MkaOh_ss0iWkqQ-1; Thu, 11 Nov 2021 06:47:35 -0500 X-MC-Unique: NH6UDy2_MkaOh_ss0iWkqQ-1 Received: by mail-wm1-f71.google.com with SMTP id z126-20020a1c7e84000000b003335e5dc26bso1353584wmc.8 for ; Thu, 11 Nov 2021 03:47:35 -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=3FPfS7kZXFceS9Lgp1RH/lsyVsBLRGLqfS3FoOXYSuE=; b=xpDjghOaRdGd1I9ciTT/plNLwLDPyaycnJWfDAwdRd5eOhc7rmqDG4OYgPkRU5QlF1 oB4gLRmBsvpYiSIbWRJ3g737QvqGylPCpXyJlc/rqnvBnBAG9GOP0PHRp8jHaFh61zZk qB9uQtMDOvrI7I7kH+gvqJWl7c+66q0UPsG53c6Q8PRTR7yPHcpvl5iyJwBLb4hBJNgG opEqjkxak/+QV+X/rKrZ5Dw8urNx3IzfKuAzVO2uiLAK/ptOcjcieWPyMmpmJzHNBPjE vvpIpoZICAmjD63lBAvdHIOrapnKi6cuGLJN8/vVASuCncFNrED1lKNIMTrXtCHM+UQa XHWA== X-Gm-Message-State: AOAM530bRNdr5BvKnpOdSlnGoBHU9X/0Pq8Yo0fLbKRG5bgIGpCAV6Rh 38yToGBNf925hbujRddLqxUyb2m1TIxkX7FyCgOIrB4Fw0FOwTyqHctgxYW4m0gpbBK4zuFQFc7 OIz4iCxjUDBk= X-Received: by 2002:a5d:45cc:: with SMTP id b12mr8082389wrs.164.1636631254686; Thu, 11 Nov 2021 03:47:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJwO566pckJvXEcwz+OG93YPsApF+toGZKExvaMFLBrnliRRTv/LgjAiYUOFAAaeaDr4bLvTMw== X-Received: by 2002:a5d:45cc:: with SMTP id b12mr8082352wrs.164.1636631254480; Thu, 11 Nov 2021 03:47:34 -0800 (PST) Received: from [192.168.3.132] (p4ff23ee8.dip0.t-ipconnect.de. [79.242.62.232]) by smtp.gmail.com with ESMTPSA id d8sm2782565wrm.76.2021.11.11.03.47.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Nov 2021 03:47:33 -0800 (PST) Message-ID: <70dd5e1c-99c9-c1ca-4e3f-1a894896cf06@redhat.com> Date: Thu, 11 Nov 2021 12:47:33 +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 4/7] fs/binfmt_elf: use get_task_comm instead of open-coded string copy 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, Kees Cook , Mathieu Desnoyers , Arnaldo Carvalho de Melo , Andrii Nakryiko , Michal Miroslaw , Peter Zijlstra , Steven Rostedt , Matthew Wilcox , Al Viro References: <20211108083840.4627-1-laoar.shao@gmail.com> <20211108083840.4627-5-laoar.shao@gmail.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: rspam03 X-Rspamd-Queue-Id: B127C3000117 X-Stat-Signature: d3zzhtkszcfw871k8hooffdn35hb1ehi Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JUG0zHkr; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf09.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1636631257-811671 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 11.11.21 12:34, Petr Mladek wrote: > On Thu 2021-11-11 11:06:04, David Hildenbrand wrote: >> On 11.11.21 11:03, David Hildenbrand wrote: >>> On 08.11.21 09:38, Yafang Shao wrote: >>>> It is better to use get_task_comm() instead of the open coded string >>>> copy as we do in other places. >>>> >>>> struct elf_prpsinfo is used to dump the task information in userspace >>>> coredump or kernel vmcore. Below is the verfication of vmcore, >>>> >>>> crash> ps >>>> PID PPID CPU TASK ST %MEM VSZ RSS COMM >>>> 0 0 0 ffffffff9d21a940 RU 0.0 0 0 [swapper/0] >>>>> 0 0 1 ffffa09e40f85e80 RU 0.0 0 0 [swapper/1] >>>>> 0 0 2 ffffa09e40f81f80 RU 0.0 0 0 [swapper/2] >>>>> 0 0 3 ffffa09e40f83f00 RU 0.0 0 0 [swapper/3] >>>>> 0 0 4 ffffa09e40f80000 RU 0.0 0 0 [swapper/4] >>>>> 0 0 5 ffffa09e40f89f80 RU 0.0 0 0 [swapper/5] >>>> 0 0 6 ffffa09e40f8bf00 RU 0.0 0 0 [swapper/6] >>>>> 0 0 7 ffffa09e40f88000 RU 0.0 0 0 [swapper/7] >>>>> 0 0 8 ffffa09e40f8de80 RU 0.0 0 0 [swapper/8] >>>>> 0 0 9 ffffa09e40f95e80 RU 0.0 0 0 [swapper/9] >>>>> 0 0 10 ffffa09e40f91f80 RU 0.0 0 0 [swapper/10] >>>>> 0 0 11 ffffa09e40f93f00 RU 0.0 0 0 [swapper/11] >>>>> 0 0 12 ffffa09e40f90000 RU 0.0 0 0 [swapper/12] >>>>> 0 0 13 ffffa09e40f9bf00 RU 0.0 0 0 [swapper/13] >>>>> 0 0 14 ffffa09e40f98000 RU 0.0 0 0 [swapper/14] >>>>> 0 0 15 ffffa09e40f9de80 RU 0.0 0 0 [swapper/15] >>>> >>>> It works well as expected. >>>> >>>> Suggested-by: Kees Cook >>>> Signed-off-by: Yafang Shao >>>> Cc: Mathieu Desnoyers >>>> Cc: Arnaldo Carvalho de Melo >>>> Cc: Andrii Nakryiko >>>> Cc: Michal Miroslaw >>>> Cc: Peter Zijlstra >>>> Cc: Steven Rostedt >>>> Cc: Matthew Wilcox >>>> Cc: David Hildenbrand >>>> Cc: Al Viro >>>> Cc: Kees Cook >>>> Cc: Petr Mladek >>>> --- >>>> fs/binfmt_elf.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c >>>> index a813b70f594e..138956fd4a88 100644 >>>> --- a/fs/binfmt_elf.c >>>> +++ b/fs/binfmt_elf.c >>>> @@ -1572,7 +1572,7 @@ static int fill_psinfo(struct elf_prpsinfo *psinfo, struct task_struct *p, >>>> SET_UID(psinfo->pr_uid, from_kuid_munged(cred->user_ns, cred->uid)); >>>> SET_GID(psinfo->pr_gid, from_kgid_munged(cred->user_ns, cred->gid)); >>>> rcu_read_unlock(); >>>> - strncpy(psinfo->pr_fname, p->comm, sizeof(psinfo->pr_fname)); >>>> + get_task_comm(psinfo->pr_fname, p); >>>> >>>> return 0; >>>> } >>>> >>> >>> We have a hard-coded "pr_fname[16]" as well, not sure if we want to >>> adjust that to use TASK_COMM_LEN? >> >> But if the intention is to chance TASK_COMM_LEN later, we might want to >> keep that unchanged. > > It seems that len will not change in the end. Another solution is > going to be used for the long names, see > https://lore.kernel.org/r/20211108084142.4692-1-laoar.shao@gmail.com. Yes, that's what I recall as well. The I read the patch subjects+descriptions in this series "make it adopt to task comm size change" and was slightly confused. Maybe we should just remove any notion of "task comm size change" from this series and instead just call it a cleanup. -- Thanks, David / dhildenb