[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230324150350.fu7itbqqvtjmyf3s@blackpad>
Date: Fri, 24 Mar 2023 16:03:50 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Florian Schmidt <flosch@...anix.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Shakeel Butt <shakeelb@...gle.com>,
Muchun Song <muchun.song@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
cgroups@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC] memcg v1: provide read access to memory.pressure_level
Hello.
On Wed, Mar 22, 2023 at 02:25:25PM +0000, Florian Schmidt <flosch@...anix.com> wrote:
> cgroups v1 has a unique way of setting up memory pressure notifications:
...
> There are several ways around this issue, but adding a dummy read
> handler seems like the least invasive to me. I'd be interested to hear:
> (a) do you think there is a less invasive way? Alternatively, we could
> add a flag in cftype in include/linux/cgroup-defs.h, but that seems
> more invasive for what is a legacy interface.
You can (as privileged user) modify file perms in userspace first (e.g.
chmod o+r memory.pressure_level) and then it can used by non-privileged
users. (Or do LSM prevent you from that too?)
> (b) would you be interested to take this patch, or is it too niche a fix
> for a legacy subsystem?
I'd rather not extend this "unique way" with additionally unique dummy
helpers.
My 0.02 €,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists