linux-kernel - Re: [RFC PATCH v3] zswap: memcontrol: implement zswap writeback disabling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF8kJuPgWjim82+HmEgkkWrDNwi2co-3ay-35fjoLb8-k9rNXQ@mail.gmail.com>
Date:   Wed, 8 Nov 2023 18:41:38 -0800
From:   Chris Li <chrisl@...nel.org>
To:     Nhat Pham <nphamcs@...il.com>
Cc:     Yosry Ahmed <yosryahmed@...gle.com>, akpm@...ux-foundation.org,
        tj@...nel.org, lizefan.x@...edance.com, hannes@...xchg.org,
        cerasuolodomenico@...il.com, sjenning@...hat.com,
        ddstreet@...e.org, vitaly.wool@...sulko.com, mhocko@...nel.org,
        roman.gushchin@...ux.dev, shakeelb@...gle.com,
        muchun.song@...ux.dev, hughd@...gle.com, corbet@....net,
        konrad.wilk@...cle.com, senozhatsky@...omium.org, rppt@...nel.org,
        linux-mm@...ck.org, kernel-team@...a.com,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        david@...t.cz
Subject: Re: [RFC PATCH v3] zswap: memcontrol: implement zswap writeback disabling

Hi Nhant,

On Fri, Nov 3, 2023 at 12:24 PM Nhat Pham <nphamcs@...il.com> wrote:
> >
> > Would it be more convenient if the initial value is inherited from the
> > parent (the root starts with true)?
> >
> > I can see this being useful if we want to set it to false on the
> > entire machine or one a parent cgroup, we can set it before creating
> > any children instead of setting it to 0 every time we create a new
> > cgroup.
>
> I'm not 100% sure about the benefit or have a strong opinion one way
> or another, but this sounds like a nice-to-have detail to me, and a relatively
> low cost one (both in effort and at runtime) at that too.
>
> Propagating the change everytime we modify the memory.zswap.writeback
> value of the ancestor might be data race-prone (and costly, depending on
> how big the cgroup subtree is), but this is just a one-time-per-cgroup
> propagation (at the new cgroup creation time).

I think Yosary was suggesting inheriting the initial value from
parents. That is just one level look up when you create the new
cgroup, using the parent value as default. No recursive.
What you described above seems different to me. I understand what you
are suggesting is that writing to the parent cgroup will recursively
write to all child cgroup.
>
> Can anyone come up with a failure case for this change, or why it might be
> a bad idea?

I would suggest against recursive changing value behavior.
What if you want the parent but also want the child to keep its value
not changed? Every change to the parent will have to go through the
child to flip it back.
Inherit from the parent seems fine.

Chris