On Thu, Aug 15, 2024 at 4:32 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > On Thu, Aug 15, 2024 at 3:10 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > On Thu, Aug 15, 2024 at 3:08 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Thu, 15 Aug 2024 12:12:26 -0700 Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > > > > > > > Yeah, I thought about the other way around and reached the same > > > > > conclusion. > > > > > And there's permission boundary in the mix too - if root disables zswap > > > > > writeback for its cgroup, the subcgroups, which could possibly be owned > > > > > by other users, should not be able to reenable this. > > > > > > > > Hmm yeah, I think I agree with your and Yosry's reasonings :) It > > > > doesn't affect our use case AFAICS, and the code looks solid to me, > > > > so: > > > > > > > > Reviewed-by: Nhat Pham <nphamcs@xxxxxxxxx> > > > > > > But you'd still like an update to Documentation/admin-guide/cgroup-v2.rst? > > > > > > Yeah I'd rather see a v2 with updated docs, and hopefully a selftest > > if the existing tests problem is resolved. > > Ah yeah, I was thinking this could be done in a follow-up patch. > > But yes, please - documentation. Preferably everything together as v2. > > > > > Also, do we want a Fixes tag and to backport this so that current > > users get the new behavior ASAP? > > Hmm, I wonder if it's more confusing for users to change the behavior > in older kernels. > > (OTOH, if this already is what people expect, then yeah it's a good > idea to backport). My rationale is that if people will inevitably get the behavior change when they upgrade their kernel, I'd rather they get it sooner rather than later, before more users start depending on the old behavior. I am guessing there is a chance this is not what backports are meant for. Andrew, any thoughts on this?
