From: Andrew Morton <akpm@linux-foundation.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Waiman Long <longman@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, Ira Weiny <ira.weiny@intel.com>,
Mike Rapoport <rppt@kernel.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <guro@fb.com>, Rafael Aquini <aquini@redhat.com>
Subject: Re: [PATCH v4 3/4] mm/page_owner: Print memcg information
Date: Mon, 7 Feb 2022 11:09:47 -0800 [thread overview]
Message-ID: <20220207110947.f07b58898d91c02090f9aacf@linux-foundation.org> (raw)
In-Reply-To: <YgFUxFI5bMbc42j4@dhcp22.suse.cz>
On Mon, 7 Feb 2022 18:20:04 +0100 Michal Hocko <mhocko@suse.com> 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.
next prev parent reply other threads:[~2022-02-07 19:09 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 19:23 [PATCH v3 0/4] mm/page_owner: Extend page_owner to show " Waiman Long
2022-01-31 19:23 ` [PATCH v3 1/4] lib/vsprintf: Avoid redundant work with 0 size Waiman Long
2022-01-31 20:42 ` Mike Rapoport
2022-01-31 19:23 ` [PATCH v3 2/4] mm/page_owner: Use scnprintf() to avoid excessive buffer overrun check Waiman Long
2022-01-31 20:38 ` Roman Gushchin
2022-01-31 20:43 ` Mike Rapoport
2022-01-31 19:23 ` [PATCH v3 3/4] mm/page_owner: Print memcg information Waiman Long
2022-01-31 20:51 ` Mike Rapoport
2022-01-31 21:43 ` Waiman Long
2022-02-01 6:23 ` Mike Rapoport
2022-01-31 20:51 ` Roman Gushchin
2022-02-01 10:54 ` Michal Hocko
2022-02-01 17:04 ` Waiman Long
2022-02-02 8:49 ` Michal Hocko
2022-02-02 16:12 ` Waiman Long
2022-01-31 19:23 ` [PATCH v3 4/4] mm/page_owner: Record task command name Waiman Long
2022-01-31 20:54 ` Roman Gushchin
2022-01-31 21:46 ` Waiman Long
2022-01-31 22:03 ` [PATCH v4 " Waiman Long
2022-02-01 15:28 ` Michal Hocko
2022-02-02 16:53 ` Waiman Long
2022-02-03 12:10 ` Vlastimil Babka
2022-02-03 18:53 ` Waiman Long
2022-02-02 20:30 ` [PATCH v4 0/4] mm/page_owner: Extend page_owner to show memcg information Waiman Long
2022-02-02 23:06 ` Rafael Aquini
2022-02-02 20:30 ` [PATCH v4 1/4] lib/vsprintf: Avoid redundant work with 0 size Waiman Long
2022-02-08 10:08 ` Petr Mladek
2022-02-02 20:30 ` [PATCH v4 2/4] mm/page_owner: Use scnprintf() to avoid excessive buffer overrun check Waiman Long
2022-02-03 15:46 ` Vlastimil Babka
2022-02-03 18:49 ` Waiman Long
2022-02-08 10:51 ` Petr Mladek
2022-02-02 20:30 ` [PATCH v4 3/4] mm/page_owner: Print memcg information Waiman Long
2022-02-03 6:53 ` Mike Rapoport
2022-02-03 12:46 ` Michal Hocko
2022-02-03 19:03 ` Waiman Long
2022-02-07 17:20 ` Michal Hocko
2022-02-07 19:09 ` Andrew Morton [this message]
2022-02-07 19:33 ` Waiman Long
2022-02-02 20:30 ` [PATCH v4 4/4] mm/page_owner: Record task command name Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220207110947.f07b58898d91c02090f9aacf@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=aquini@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=ira.weiny@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=longman@redhat.com \
--cc=mhocko@suse.com \
--cc=pmladek@suse.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=senozhatsky@chromium.org \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox