linux-kernel - Re: [RFC][-mm] Add an owner to the mm

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: <47F4577E.5060905@linux.vnet.ibm.com>
Date:	Thu, 03 Apr 2008 09:35:18 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Paul Menage <menage@...gle.com>
CC:	Pavel Emelianov <xemul@...nvz.org>,
	Hugh Dickins <hugh@...itas.com>,
	Sudhir Kumar <skumar@...ux.vnet.ibm.com>,
	YAMAMOTO Takashi <yamamoto@...inux.co.jp>, lizf@...fujitsu.com,
	linux-kernel@...r.kernel.org, taka@...inux.co.jp,
	linux-mm@...ck.org, David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [RFC][-mm] Add an owner to the mm_struct (v4)

Paul Menage wrote:
> On Wed, Apr 2, 2008 at 11:53 AM, Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
>>  So far I've heard no objections or seen any review suggestions. Paul if you are
>>  OK with this patch, I'll ask Andrew to include it in -mm.
> 
> My only thoughts were:
> 
> - I think I'd still prefer CONFIG_MM_OWNER to be auto-selected rather
> than manually configured, but it's not a huge deal either way.
> 

It is auto-selected now by CONFIG_CGROUP_MEM_RES_CTLR in the latest patchset

> - in theory I think we should goto retry if we get to the end of
> mm_update_next_owner() without finding any other owner. Otherwise we
> could miss another user if we race with one process forking a new
> child and then exiting?
> 

When we the current task is exiting and we've verified that we are mm->owner and
we cannot miss the new process since through the process of forking, it would
have added the new process to the tasklist before exiting.

> - I was looking through the exit code trying to convince myself that
> current is still on the tasklist until after it makes this call. If it
> isn't then we could have trouble finding the new owner. But I can't
> figure out for sure exactly at what point we come off the tasklist.
> 

We come off the task list in __unhash_process(), which is in turn called by
release_task() through __exit_signal().

> - I think we only need the cgroup callback in the event that
> current->cgroups != new_owner->cgroups. (Hmm, have we already been
> moved back to the root cgroup by this point? If so, then we'll have no
> way to know which cgruop to unaccount from).
> 

I checked to see that cgroup_exit is called after mm_update_new_owner(). We call
mm_update_new_owner() from exit_mm(). I did not check for current->cgroups !=
new_owner->cgroups, since I did not want to limit the callbacks. An interested
callback can make that check and no-op the callback.

I am going to change the rcu_read_lock(), so that it is released after we take
the task_lock() and repost the patch


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/