Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 27 Mar 2023 22:40:37 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     Florian Schmidt <flosch@nutanix.com>
Cc:     Michal =?iso-8859-1?Q?Koutn=FD?= <mkoutny@suse.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        Shakeel Butt <shakeelb@google.com>,
        Muchun Song <muchun.song@linux.dev>,
        Andrew Morton <akpm@linux-foundation.org>,
        cgroups@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC] memcg v1: provide read access to memory.pressure_level
Message-ID: <ZCH/RVlh1M6DRXaU@dhcp22.suse.cz>
References: <20230322142525.162469-1-flosch@nutanix.com>
 <20230324150350.fu7itbqqvtjmyf3s@blackpad>
 <6f4420d0-2f86-7294-01e1-6806ef7e4686@nutanix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6f4420d0-2f86-7294-01e1-6806ef7e4686@nutanix.com>
Precedence: bulk

On Mon 27-03-23 14:59:37, Florian Schmidt wrote:
> Hi Michal,
> 
> On 24/03/2023 15:03, Michal Koutn? wrote:
> > On Wed, Mar 22, 2023 at 02:25:25PM +0000, Florian Schmidt <flosch@nutanix.com> wrote:
[...]
> > > (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.
> 
> I understand that this is all code that has no modern user any more, which
> is why I tried to keep the fix as self-contained as possible.
> Another option would be to have a special handler in cgroup_file_mode(), but
> that feels a lot klunkier to me, and leaks a v1-specific behaviour into the
> shared cgroup code.

Yes, this is effectivelly a deprecated interface but I do agree that we
shouldn't really make life of users more complicated than necessary. If
the simplest solution to address this is to provide an empty callback
then be it. I am not sure but I do not think there are other cgroup
interfaces to warrant a more generic solution.

-- 
Michal Hocko
SUSE Labs