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 AEC55C433EF for ; Mon, 7 Feb 2022 19:09:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 421416B0074; Mon, 7 Feb 2022 14:09:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CEED6B0075; Mon, 7 Feb 2022 14:09:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BE236B0078; Mon, 7 Feb 2022 14:09:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id 1D0366B0074 for ; Mon, 7 Feb 2022 14:09:51 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D003B8249980 for ; Mon, 7 Feb 2022 19:09:50 +0000 (UTC) X-FDA: 79116923340.06.B4E4D94 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 5B96614000B for ; Mon, 7 Feb 2022 19:09:50 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 40CEE61469; Mon, 7 Feb 2022 19:09:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F935C340EE; Mon, 7 Feb 2022 19:09:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1644260988; bh=1RclloxgFVd2RY/SeAe+aZcV9sRA2fEBnErBCQ5PRjk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FFY2E0gZcn+hlSYQnpefUNBA1l5rE11wEoXKl40YqV1L1HpuqhxmQ+kJNZu2t373W AjoDjYCQxy2ZubNzmVoAB4s6o/jE/wIg65oRrZ4Gg/7IbWTaQBO1slEgGnuCXBGRd7 L+OKUzs+E87cP4vkY5QndLicBOgQ4Yc4qujZ4vsU= Date: Mon, 7 Feb 2022 11:09:47 -0800 From: Andrew Morton To: Michal Hocko Cc: Waiman Long , Johannes Weiner , Vladimir Davydov , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Ira Weiny , Mike Rapoport , David Rientjes , Roman Gushchin , Rafael Aquini Subject: Re: [PATCH v4 3/4] mm/page_owner: Print memcg information Message-Id: <20220207110947.f07b58898d91c02090f9aacf@linux-foundation.org> In-Reply-To: References: <20220131192308.608837-5-longman@redhat.com> <20220202203036.744010-4-longman@redhat.com> <3f042edb-3769-afea-17a7-899578cd5c69@redhat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: ocad3z57u77epnknczxqrm5i7dqqpgzq X-Rspam-User: nil Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=FFY2E0gZ; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5B96614000B X-HE-Tag: 1644260990-945543 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 Mon, 7 Feb 2022 18:20:04 +0100 Michal Hocko wrote: > On Thu 03-02-22 14:03:58, Waiman Long wrote: > > On 2/3/22 07:46, Michal Hocko wrote: > > > On Wed 02-02-22 15:30:35, Waiman Long wrote: > > > [...] > ... > > > > + online = (memcg->css.flags & CSS_ONLINE); > > > > + cgroup_name(memcg->css.cgroup, name, sizeof(name)); > > > Is there any specific reason to use another buffer allocated on the > > > stack? Also 80B seems too short to cover NAME_MAX. > > > > > > Nothing else jumped at me. > > > > I suppose we can print directly into kbuf with cgroup_name(), but using a > > separate buffer is easier to read and understand. 79 characters should be > > enough for most cgroup names. Some auto-generated names with some kind of > > embedded uuids may be longer than that, but the random sequence of hex > > digits that may be missing do not convey much information for identification > > purpose. We can always increase the buffer length later if it turns out to > > be an issue. > > Cutting a name short sounds like a source of confusion and there doesn't > seem to be any good reason for that. Yes. If we give them 79 characters, someone will go and want 94. If we can prevent this once and for ever, let's please do so.