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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 8 Nov 2023 19:08:50 -0800
From:   Nhat Pham <nphamcs@...il.com>
To:     Chris Li <chrisl@...nel.org>
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

On Wed, Nov 8, 2023 at 6:41 PM Chris Li <chrisl@...nel.org> wrote:
>
> 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

Hi Chris,

I've actually sent out a new version of the patch series implementing
(what I believed to be) Yosry's suggestion. Feel free to take a look!

https://lore.kernel.org/all/20231106231158.380730-1-nphamcs@gmail.com/

Here, I was actually agreeing with you - recursive propagation would
not be a good idea.

Best,
Nhat