On Thu, Oct 24, 2024 at 11:14:01AM +0200, Michal Hocko wrote: > On Wed 23-10-24 23:57:10, Shakeel Butt wrote: > > Proceed with the complete deprecation of memcg v1's charge moving > > feature. The deprecation warning has been in the kernel for almost two > > years and has been ported to all stable kernel since. Now is the time to > > fully deprecate this feature. > > > > Signed-off-by: Shakeel Butt <shakeel.butt@xxxxxxxxx> > > I fine with this move, just one detail we might need to consider > [...] > > @@ -606,17 +606,7 @@ static int mem_cgroup_move_charge_write(struct cgroup_subsys_state *css, > > "Please report your usecase to linux-mm@xxxxxxxxx if you " > > "depend on this functionality.\n"); > > > > - if (val & ~MOVE_MASK) > > - return -EINVAL; > > - > > - /* > > - * No kind of locking is needed in here, because ->can_attach() will > > - * check this value once in the beginning of the process, and then carry > > - * on with stale data. This means that changes to this value will only > > - * affect task migrations starting after the change. > > - */ > > - memcg->move_charge_at_immigrate = val; > > - return 0; > > + return -EINVAL; > > Would it make more sense to -EINVAL only if val != 0? The reason being > that some userspace might be just writing 0 here for whatever reason and > see the failure unexpected. I think it's a good idea. Thanks!
