From: Arun Sharma <asharma@fb.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Balbir Singh <bsingharora@gmail.com>,
akpm@linux-foundation.org
Subject: Re: [PATCH] mm: Enable MAP_UNINITIALIZED for archs with mmu
Date: Mon, 23 Jan 2012 16:54:22 -0800 [thread overview]
Message-ID: <4F1E013E.9060009@fb.com> (raw)
In-Reply-To: <20120119114206.653b88bd.kamezawa.hiroyu@jp.fujitsu.com>
On 1/18/12 6:42 PM, KAMEZAWA Hiroyuki wrote:
>
> Hmm, then,
> 1. a new task jumped into this cgroup can see any uncleared data...
> 2. if a memcg pointer is reused, the information will be leaked.
You're suggesting mm_match_cgroup() is good enough for accounting
purposes, but not usable for cases where its important to get the
equality right?
> 3. If VM_UNINITALIZED is set, the process can see any data which
> was freed by other process which doesn't know VM_UNINITALIZED at all.
>
> 4. The process will be able to see file cache data which the it has no
> access right if it's accessed by memcg once.
>
> 3& 4 seems too danger.
Yes - these are the risks that I'm hoping we can document, so the
cgroups admin can avoid opting-in if not everything running in the
cgroup is trusted.
>
> Isn't it better to have this as per-task rather than per-memcg ?
> And just allow to reuse pages the page has freed ?
>
I'm worrying that the additional complexity of maintaining a per-task
page list would be a problem. It might slow down workloads that
alloc/free a lot because of the added code. It'll probably touch the
kswapd as well (for reclaiming pages from the per-task free lists under
low mem conditions).
Did you have some implementation ideas which would not have the problems
above?
-Arun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Arun Sharma <asharma@fb.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
Balbir Singh <bsingharora@gmail.com>, <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: Enable MAP_UNINITIALIZED for archs with mmu
Date: Mon, 23 Jan 2012 16:54:22 -0800 [thread overview]
Message-ID: <4F1E013E.9060009@fb.com> (raw)
In-Reply-To: <20120119114206.653b88bd.kamezawa.hiroyu@jp.fujitsu.com>
On 1/18/12 6:42 PM, KAMEZAWA Hiroyuki wrote:
>
> Hmm, then,
> 1. a new task jumped into this cgroup can see any uncleared data...
> 2. if a memcg pointer is reused, the information will be leaked.
You're suggesting mm_match_cgroup() is good enough for accounting
purposes, but not usable for cases where its important to get the
equality right?
> 3. If VM_UNINITALIZED is set, the process can see any data which
> was freed by other process which doesn't know VM_UNINITALIZED at all.
>
> 4. The process will be able to see file cache data which the it has no
> access right if it's accessed by memcg once.
>
> 3& 4 seems too danger.
Yes - these are the risks that I'm hoping we can document, so the
cgroups admin can avoid opting-in if not everything running in the
cgroup is trusted.
>
> Isn't it better to have this as per-task rather than per-memcg ?
> And just allow to reuse pages the page has freed ?
>
I'm worrying that the additional complexity of maintaining a per-task
page list would be a problem. It might slow down workloads that
alloc/free a lot because of the added code. It'll probably touch the
kswapd as well (for reclaiming pages from the per-task free lists under
low mem conditions).
Did you have some implementation ideas which would not have the problems
above?
-Arun
next prev parent reply other threads:[~2012-01-24 0:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-18 18:51 [PATCH] mm: Enable MAP_UNINITIALIZED for archs with mmu Arun Sharma
2012-01-18 18:51 ` Arun Sharma
2012-01-19 2:42 ` KAMEZAWA Hiroyuki
2012-01-19 2:42 ` KAMEZAWA Hiroyuki
2012-01-24 0:54 ` Arun Sharma [this message]
2012-01-24 0:54 ` Arun Sharma
2012-01-24 3:07 ` KAMEZAWA Hiroyuki
2012-01-24 3:07 ` KAMEZAWA Hiroyuki
2012-01-25 1:45 ` Arun Sharma
2012-01-25 1:45 ` Arun Sharma
2012-02-22 0:34 ` Arun Sharma
2012-02-22 0:34 ` Arun Sharma
2012-02-23 7:45 ` Balbir Singh
2012-02-23 7:45 ` Balbir Singh
2012-02-23 18:42 ` Arun Sharma
2012-02-23 18:42 ` Arun Sharma
2012-02-24 2:47 ` KAMEZAWA Hiroyuki
2012-02-24 2:47 ` KAMEZAWA Hiroyuki
2012-02-24 14:51 ` Balbir Singh
2012-02-24 14:51 ` Balbir Singh
2012-02-24 19:11 ` Arun Sharma
2012-02-24 19:11 ` Arun Sharma
2012-02-25 4:13 ` Balbir Singh
2012-02-25 4:13 ` Balbir Singh
2012-02-27 18:32 ` Arun Sharma
2012-02-27 18:32 ` Arun Sharma
2012-02-24 19:26 ` Arun Sharma
2012-02-24 19:26 ` Arun Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F1E013E.9060009@fb.com \
--to=asharma@fb.com \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.