linux-kernel - Re: [PATCH 1/4] mm/swap, memcg: Introduce infrastructure for cgroup-based swap priority

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACePvbU2iqLyjc2uR3d=56S4A-N4P7k3oUnwA-6D=TFfQ17jBA@mail.gmail.com>
Date: Wed, 3 Sep 2025 02:32:25 -0700
From: Chris Li <chrisl@...nel.org>
To: YoungJun Park <youngjun.park@....com>
Cc: Michal Koutný <mkoutny@...e.com>, 
	akpm@...ux-foundation.org, hannes@...xchg.org, mhocko@...nel.org, 
	roman.gushchin@...ux.dev, shakeel.butt@...ux.dev, muchun.song@...ux.dev, 
	shikemeng@...weicloud.com, kasong@...cent.com, nphamcs@...il.com, 
	bhe@...hat.com, baohua@...nel.org, cgroups@...r.kernel.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, gunho.lee@....com, 
	iamjoonsoo.kim@....com, taejoon.song@....com, 
	Matthew Wilcox <willy@...radead.org>, David Hildenbrand <david@...hat.com>, Kairui Song <ryncsn@...il.com>
Subject: Re: [PATCH 1/4] mm/swap, memcg: Introduce infrastructure for
 cgroup-based swap priority

On Mon, Sep 1, 2025 at 3:40 PM Chris Li <chrisl@...nel.org> wrote:
> You are missing the fact that you need to track two sets of the tier mask.
> the "swap.ters" is a local tiername you need to track. Default is empty.
>
> The runtime tier set is the local tier mask walk to the parent, and
> collect all parent local bitmasks and aggregate into an effective set.
> The effective tier bitmask is used as the swap allocator.
>
> What you purpose still has the same problem at:
> 1) parent "- +ssd"
> 2) child "' # same as parent.
>
> If we do what your proposal is. Child will have "ssd" on the bit mask
> at creation
> When parents remove the "ssd". the child will keep having the "ssd".
>
> In  my original proposal, if a parent removes ssd then the child will
> automatically get it as well.
>
> I am not happy that you keep introducing change to my proposal and
> introduce the same buggy behavior again and again. Please respect my
> time, I am spending my long weekend writing an email to you. Please
> don't introduce the same bug again just for the sake of changing
> behavior. Be careful and think through what you are proposing.

Please accept the sincere apology from me.  I was grumpy, sorry about
that. I was under pressure to be somewhere else but this email is
taking longer than I expected to write. I let my bad temper get the
better of me and I am sorry about that.

You might not have realized that the proposal you made has the same
kind of buggy behavior for the usage case where the change of the
parent and the child gets it.

One side note, I do want to rate limit the new proposals I have to
defend against. On the other hand, when you make a proposal to change,
you have no way to predict where I will consider it good or bad.
Otherwise we don't need to have this discussion. My hash reply is
uncalled for and I realized that now.

I am over it now, let's put this behind us and continue our discussion.

Best regards,

Chris