From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Michal Hocko <mhocko@suse.com>,
Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
Cc: stable@vger.kernel.org, patches@lists.linux.dev,
Shakeel Butt <shakeelb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
mathieu.tortuyaux@gmail.com
Subject: Re: [REGRESSION] Re: [PATCH 6.1 033/219] memcg: drop kmem.limit_in_bytes
Date: Wed, 20 Sep 2023 11:25:08 +0200 [thread overview]
Message-ID: <2023092032-applied-gave-0bff@gregkh> (raw)
In-Reply-To: <ZQqwzK/fDm+GLiKM@dhcp22.suse.cz>
On Wed, Sep 20, 2023 at 10:43:56AM +0200, Michal Hocko wrote:
> On Wed 20-09-23 01:11:01, Jeremi Piotrowski wrote:
> > On Sun, Sep 17, 2023 at 09:12:40PM +0200, Greg Kroah-Hartman wrote:
> > > 6.1-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> >
> > Hi Greg/Michal,
> >
> > This commit breaks userspace which makes it a bad commit for mainline and an
> > even worse commit for stable.
> >
> > We ingested 6.1.54 into our nightly testing and found that runc fails to gather
> > cgroup statistics (when reading kmem.limit_in_bytes). The same code is vendored
> > into kubelet and kubelet fails to start if this operation fails. 6.1.53 is
> > fine.
>
> Could you expand some more on why is the file read? It doesn't support
> writing to it for some time so how does reading it helps in any sense?
>
> Anyway, I do agree that the stable backport should be reverted.
That will just postpone the breakage, we really shouldn't break
userspace.
That being said, having userspace "break" because a file is no longer
present is not good coding style on the userspace side at all. That's
why we have sysfs and single-value-files now, if the file isn't present,
then userspace instantly notices and can handle it. Much easier than
the old-style multi-fields-in-one-file problem.
> > > Address this by wiping out the file completely and effectively get back to
> > > pre 4.5 era and CONFIG_MEMCG_KMEM=n configuration.
The fact that this is a valid option (i.e. no file) with that config
option disabled makes me want to keep this as well, as how does
userspace handle this option disabled at all? Or old kernels?
I can drop this from stable kernels, but again, this feels like the runc
developers are just postponing the problem...
thanks,
greg k-h
next prev parent reply other threads:[~2023-09-20 9:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-17 19:12 [PATCH 6.1 000/219] 6.1.54-rc1 review Greg Kroah-Hartman
2023-09-17 20:47 ` SeongJae Park
2023-09-18 5:34 ` Takeshi Ogasawara
2023-09-18 6:42 ` Bagas Sanjaya
2023-09-18 11:24 ` Conor Dooley
2023-09-18 12:08 ` Ron Economos
2023-09-18 12:48 ` Jon Hunter
2023-09-18 18:34 ` Florian Fainelli
2023-09-18 18:41 ` Guenter Roeck
2023-09-18 20:56 ` Naresh Kamboju
2023-09-18 22:21 ` Shuah Khan
[not found] ` <20230917191042.204185566@linuxfoundation.org>
2023-09-20 8:11 ` [REGRESSION] Re: [PATCH 6.1 033/219] memcg: drop kmem.limit_in_bytes Jeremi Piotrowski
2023-09-20 8:43 ` Michal Hocko
2023-09-20 9:25 ` Greg Kroah-Hartman [this message]
2023-09-20 10:21 ` Jeremi Piotrowski
2023-09-20 10:45 ` Greg Kroah-Hartman
2023-09-20 11:08 ` Michal Hocko
2023-09-20 11:16 ` Greg Kroah-Hartman
2023-09-20 10:04 ` Jeremi Piotrowski
2023-09-20 11:07 ` Michal Hocko
2023-09-20 13:25 ` Jeremi Piotrowski
2023-09-20 13:47 ` Michal Hocko
2023-09-20 15:32 ` Shakeel Butt
2023-09-20 16:55 ` Michal Hocko
2023-09-20 19:46 ` Shakeel Butt
2023-09-20 20:08 ` Michal Hocko
2023-09-20 21:46 ` Shakeel Butt
2023-09-21 7:52 ` Michal Hocko
2023-09-21 10:43 ` Jeremi Piotrowski
2023-09-21 11:21 ` Michal Hocko
2023-09-21 17:25 ` Shakeel Butt
2023-09-21 19:50 ` Michal Hocko
2023-09-22 13:30 ` Johannes Weiner
2023-09-25 7:40 ` Michal Hocko
2023-09-22 23:00 ` Roman Gushchin
2023-09-25 7:41 ` Michal Hocko
2023-09-26 2:49 ` Roman Gushchin
2023-09-22 11:14 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-09-21 13:04 ` [PATCH 6.1 000/219] 6.1.54-rc1 review Conor Dooley
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=2023092032-applied-gave-0bff@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=jpiotrowski@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.tortuyaux@gmail.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=patches@lists.linux.dev \
--cc=regressions@lists.linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
/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