From: Michal Hocko <mhocko@suse.com>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Xiu Jianfeng <xiujianfeng@huawei.com>,
hannes@cmpxchg.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev,
akpm@linux-foundation.org, cgroups@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] mm: memcg: remove redundant seq_buf_has_overflowed()
Date: Thu, 27 Jun 2024 14:28:13 +0200 [thread overview]
Message-ID: <Zn1a3RoRFMWK4XnL@tiehlicka> (raw)
In-Reply-To: <CAJD7tkb9-qzYGOMHu1DfCSsWmRfCuK5Vi3NBmTz6d-dvaeAAtw@mail.gmail.com>
On Thu 27-06-24 05:00:18, Yosry Ahmed wrote:
> On Thu, Jun 27, 2024 at 4:56 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Thu 27-06-24 04:33:50, Yosry Ahmed wrote:
> > > On Thu, Jun 27, 2024 at 12:13 AM Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > > > On Wed 26-06-24 09:42:32, Xiu Jianfeng wrote:
> > > > > Both the end of memory_stat_format() and memcg_stat_format() will call
> > > > > WARN_ON_ONCE(seq_buf_has_overflowed()). However, memory_stat_format()
> > > > > is the only caller of memcg_stat_format(), when memcg is on the default
> > > > > hierarchy, seq_buf_has_overflowed() will be executed twice, so remove
> > > > > the reduntant one.
> > > >
> > > > Shouldn't we rather remove both? Are they giving us anything useful
> > > > actually? Would a simpl pr_warn be sufficient? Afterall all we care
> > > > about is to learn that we need to grow the buffer size because our stats
> > > > do not fit anymore. It is not really important whether that is an OOM or
> > > > cgroupfs interface path.
> > >
> > > Is it possible for userspace readers to break if the stats are
> > > incomplete?
> >
> > They will certainly get an imprecise picture. Sufficient to break I
> > dunno.
>
> If some stats go completely missing and a parser expects them to
> always be there, I think they may break.
If they break, we will eventually learn about that with or without
warning. It is true that WARN* is so vocal that people/tooling might
just report that even without breakage but that to me sounds like
abusing WARNING. There were times when this was not a big deal but now
when WARN* are getting CVEs because panic_on_warn this useful debugging
tool has become a new BUG on.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2024-06-27 12:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 9:42 [PATCH -next] mm: memcg: remove redundant seq_buf_has_overflowed() Xiu Jianfeng
2024-06-27 7:13 ` Michal Hocko
2024-06-27 8:33 ` xiujianfeng
2024-06-27 11:20 ` Michal Hocko
2024-06-27 11:43 ` xiujianfeng
2024-06-27 11:54 ` Michal Hocko
2024-06-28 2:20 ` xiujianfeng
2024-06-28 7:09 ` Michal Hocko
2024-06-27 11:33 ` Yosry Ahmed
2024-06-27 11:56 ` Michal Hocko
2024-06-27 12:00 ` Yosry Ahmed
2024-06-27 12:28 ` Michal Hocko [this message]
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=Zn1a3RoRFMWK4XnL@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=xiujianfeng@huawei.com \
--cc=yosryahmed@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.