lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z8iadfcPxgamx9CC@slm.duckdns.org>
Date: Wed, 5 Mar 2025 08:39:49 -1000
From: Tejun Heo <tj@...nel.org>
To: Michal Koutný <mkoutny@...e.com>
Cc: Waiman Long <llong@...hat.com>, cgroups@...r.kernel.org,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	Josef Bacik <josef@...icpanda.com>, Jens Axboe <axboe@...nel.dk>,
	Johannes Weiner <hannes@...xchg.org>
Subject: Re: [PATCH 1/9] cgroup/cpuset-v1: Add deprecation warnings to
 sched_load_balance and memory_pressure_enabled

Hello,

On Wed, Mar 05, 2025 at 11:12:21AM +0100, Michal Koutný wrote:
> On Tue, Mar 04, 2025 at 08:04:06AM -1000, Tejun Heo <tj@...nel.org> wrote:
> > I'm apprehensive about adding warning messages which may be triggered
> > consistently without anything end users can do about them.
> 
> That means you'd distinguish RE (replacement exists) vs DN (dropped as
> non-ideal) categories?

I don't think I am. I'm just concerned about emitting warn messages on every
boot without users being able to do anything about them.

> > I think that deprecation messages, unless such deprecation is
> > immediate and would have direct consequences on how the system can be
> > used, should be informational.
> 
> I could subscribe to that if there weren't so many other places to
> evaluate:
>   $ git grep -i "pr_warn.*deprec" torvalds/master --  | wc -l
>   62
>   $ git grep -i "pr_info.*deprec" torvalds/master --  | wc -l
>   2
> 
> So is the disctinction worth the hassle?

Well, not all deprecations are the same. If users are stuck on cgroup1, they
can be really stuck - there can be a tall stack of software with
dependencies that users can't do much about, at least not immediately. We
will deprecate cgroup1 but this is going to be a long stretched out process
at the end of which we should be fairly comfortable in stating that there
aren't major users left which are stuck on cgroup1.

It's almost certain that that future won't arrive in, say, three years. Five
years may be too ambitious too but let's say that at that point we are
relatively sure that most platforms have moved on (but there may still be
users on older versions of those platforms). Maybe it'd make sense to
increase the deprecation warning temperature by then to warn and drain
existing users and maybe after a few years we'd actually be able to drop
cgroup1 support.

So, I don't want to be emitting warnings on every boot for the good part of
a decade on every boot for those users. Doing so feels silly and annoying to
me. Let's inform that it's coming down the pipeline but I personally don't
want to be warned by something that's close to a decade out.

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ