linux-kernel - Re: [PATCH rfc 2/5] mm: kmem: add direct objcg pointer to task

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: <ZRs-RKsOhtO3eclx@P9FQF9L96D>
Date:   Mon, 2 Oct 2023 15:03:48 -0700
From:   Roman Gushchin <roman.gushchin@...ux.dev>
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        cgroups@...r.kernel.org, Michal Hocko <mhocko@...nel.org>,
        Shakeel Butt <shakeelb@...gle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Dennis Zhou <dennis@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH rfc 2/5] mm: kmem: add direct objcg pointer to task_struct

On Mon, Oct 02, 2023 at 04:12:54PM -0400, Johannes Weiner wrote:
> On Wed, Sep 27, 2023 at 08:08:29AM -0700, Roman Gushchin wrote:
> > @@ -3001,6 +3001,47 @@ static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg)
> >  	return objcg;
> >  }
> >  
> > +static DEFINE_SPINLOCK(current_objcg_lock);
> > +
> > +static struct obj_cgroup *current_objcg_update(struct obj_cgroup *old)
> > +{
> > +	struct mem_cgroup *memcg;
> > +	struct obj_cgroup *objcg;
> > +	unsigned long flags;
> > +
> > +	old = current_objcg_clear_update_flag(old);
> > +	if (old)
> > +		obj_cgroup_put(old);
> > +
> > +	spin_lock_irqsave(&current_objcg_lock, flags);
> > +	rcu_read_lock();
> > +	memcg = mem_cgroup_from_task(current);
> > +	for (; memcg != root_mem_cgroup; memcg = parent_mem_cgroup(memcg)) {
> > +		objcg = rcu_dereference(memcg->objcg);
> > +		if (objcg && obj_cgroup_tryget(objcg))
> > +			break;
> > +		objcg = NULL;
> > +	}
> > +	rcu_read_unlock();
> 
> Can this tryget() actually fail when this is called on the current
> task during fork() and attach()? A cgroup cannot be offlined while
> there is a task in it.

Highly theoretically it can if it races against a migration of the current
task to another memcg and the previous memcg is getting offlined.

I actually might make sense to apply the same approach for memcgs as well
(saving a lazily-updating memcg pointer on task_struct). Then it will be
possible to ditch this "for" loop. But I need some time to master the code
and run benchmarks. Idk if it will make enough difference to justify the change.

Btw, this is the rfc version, while there is a newer v1 version, which Andrew
already picked for mm-unstable. Both of your comments still apply, just fyi.

> 
> > @@ -6345,6 +6393,22 @@ static void mem_cgroup_move_task(void)
> >  		mem_cgroup_clear_mc();
> >  	}
> >  }
> > +
> > +#ifdef CONFIG_MEMCG_KMEM
> > +static void mem_cgroup_fork(struct task_struct *task)
> > +{
> > +	task->objcg = (struct obj_cgroup *)0x1;
> 
> dup_task_struct() will copy this pointer from the old task. Would it
> be possible to bump the refcount here instead? That would save quite a
> bit of work during fork().

Yeah, it should be possible. It won't save a lot, but I agree it makes
sense. I'll take a look and will prepare a separate patch for this.

Thank you!