On Tue, Feb 22, 2011 at 07:03:58PM -0500, Vivek Goyal wrote:
I think we should accept to have an inode granularity. We could redesign
the writeback code to work per-cgroup / per-page, etc. but that would
add a huge overhead. The limit of inode granularity could be an
acceptable tradeoff,
On Tue, Feb 22, 2011 at 07:07:19PM -0500, Vivek Goyal wrote:
On Wed, Feb 23, 2011 at 12:05:34AM +0100, Andrea Righi wrote:
On Tue, Feb 22, 2011 at 04:00:30PM -0500, Vivek Goyal wrote:
On Tue, Feb 22, 2011 at 06:12:55PM +0100, Andrea Righi wrote:
Add the tracking of buffered (writeback)
On Wed, Feb 23, 2011 at 01:49:10PM +0900, KAMEZAWA Hiroyuki wrote:
On Wed, 23 Feb 2011 00:37:18 +0100
Andrea Righi ari...@develer.com wrote:
On Tue, Feb 22, 2011 at 06:06:30PM -0500, Vivek Goyal wrote:
On Wed, Feb 23, 2011 at 12:01:47AM +0100, Andrea Righi wrote:
On Tue, Feb 22, 2011
David Howells dhowe...@redhat.com wrote:
int (*capable) (struct task_struct *tsk, const struct cred *cred,
- int cap, int audit);
+ struct user_namespace *ns, int cap, int audit);
Hmmm... A chunk of the contents of the cred struct are
I guess we need to look at how to mix keys and namespaces again.
Possibly the trickiest problem with keys is how to upcall key construction to
/sbin/request-key when the keys may be of a different user namespace.
David
___
Containers mailing list
Quoting David Howells (dhowe...@redhat.com):
David Howells dhowe...@redhat.com wrote:
int (*capable) (struct task_struct *tsk, const struct cred *cred,
- int cap, int audit);
+ struct user_namespace *ns, int cap, int audit);
Hmmm... A chunk of
Quoting David Howells (dhowe...@redhat.com):
I guess we need to look at how to mix keys and namespaces again.
From strictly kernel pov, at the moment, keys are strictly usable only
by the user in your own user namespace.
We may want to look at this again, but for now I think that would be a
Serge E. Hallyn se...@hallyn.com writes:
Quoting David Howells (dhowe...@redhat.com):
I guess we need to look at how to mix keys and namespaces again.
From strictly kernel pov, at the moment, keys are strictly usable only
by the user in your own user namespace.
We may want to look at this
Serge E. Hallyn se...@hallyn.com wrote:
I guess we need to look at how to mix keys and namespaces again.
From strictly kernel pov, at the moment, keys are strictly usable only
by the user in your own user namespace.
I'm not sure that's currently completely true. Key quota maintenance is
Agreed. Granularity of per inode level might be accetable in many
cases. Again, I am worried faster group getting stuck behind slower
group.
I am wondering if we are trying to solve the problem of ASYNC write
throttling
at wrong layer. Should ASYNC IO be throttled before we allow
David Howells dhowe...@redhat.com writes:
Serge E. Hallyn se...@hallyn.com wrote:
I guess we need to look at how to mix keys and namespaces again.
From strictly kernel pov, at the moment, keys are strictly usable only
by the user in your own user namespace.
I'm not sure that's currently
Quoting Eric W. Biederman (ebied...@xmission.com):
David Howells dhowe...@redhat.com writes:
Serge E. Hallyn se...@hallyn.com wrote:
I guess we need to look at how to mix keys and namespaces again.
From strictly kernel pov, at the moment, keys are strictly usable only
by the user
Serge E. Hallyn se...@hallyn.com wrote:
+ /* If you have the capability in a parent user ns you have it
+ * in the over all children user namespaces as well, so see
+ * if this process has the capability in the parent user
+ * namespace.
+
Serge E. Hallyn se...@hallyn.com wrote:
ptrace is allowed to tasks in the same user namespace according to
There's a verb missing after 'allowed to' - presumably 'trace'.
David
___
Containers mailing list
contain...@lists.linux-foundation.org
Serge E. Hallyn se...@hallyn.com wrote:
+int same_or_ancestor_user_ns(struct task_struct *task,
+ struct task_struct *victim)
+{
+ struct user_namespace *u1 = task_cred_xxx(task, user)-user_ns;
+ struct user_namespace *u2 = task_cred_xxx(victim, user)-user_ns;
Hmmm.
Serge E. Hallyn se...@hallyn.com wrote:
struct uts_namespace {
struct kref kref;
struct new_utsname name;
+ struct user_namespace *user_ns;
};
If a uts_namespace belongs to a user_namespace, should CLONE_NEWUSER then
imply CLONE_NEWUTS?
Or is uts_namespace::user_ns more
Casey Schaufler ca...@schaufler-ca.com writes:
I confess that I remain less well educated on namespaces than
I probably should be, but with what I do know it seems that the
relationships between user namespaces and LSMs are bound to be
strained from the beginning. Some LSMs (SELinux and
David Howells dhowe...@redhat.com writes:
Serge E. Hallyn se...@hallyn.com wrote:
struct uts_namespace {
struct kref kref;
struct new_utsname name;
+struct user_namespace *user_ns;
};
If a uts_namespace belongs to a user_namespace, should CLONE_NEWUSER then
imply
On 2/23/2011 12:55 PM, Eric W. Biederman wrote:
Casey Schaufler ca...@schaufler-ca.com writes:
I confess that I remain less well educated on namespaces than
I probably should be, but with what I do know it seems that the
relationships between user namespaces and LSMs are bound to be
strained
On Wed, Feb 23, 2011 at 10:23:54AM -0500, Vivek Goyal wrote:
Agreed. Granularity of per inode level might be accetable in many
cases. Again, I am worried faster group getting stuck behind slower
group.
I am wondering if we are trying to solve the problem of ASYNC write
Eric W. Biederman ebied...@xmission.com wrote:
Which means that unless the uts_namespace belongs to our user_namespace, we
cannot change it. Is that correct?
No. If you are root in a parent namespace you can also change it.
But surely, by definition, if you're a user in this namespace,
On Wed, 23 Feb 2011 09:59:11 +0100
Andrea Righi ari...@develer.com wrote:
I wonder I can make pc-mem_cgroup to be pc-memid(16bit), then,
==
static inline struct mem_cgroup *get_memcg_from_pc(struct page_cgroup *pc)
{
struct cgroup_subsys_state *css =
On Thu, Feb 24, 2011 at 12:14:11AM +0100, Andrea Righi wrote:
On Wed, Feb 23, 2011 at 10:23:54AM -0500, Vivek Goyal wrote:
Agreed. Granularity of per inode level might be accetable in many
cases. Again, I am worried faster group getting stuck behind slower
group.
I am
To do so we need to pass in the task_struct who'll get the utsname,
so we can get its user_ns.
Changelog:
Feb 23: As per Oleg's coment, just pass in tsk.
Signed-off-by: Serge E. Hallyn serge.hal...@canonical.com
---
include/linux/utsname.h |6 +++---
kernel/nsproxy.c|7
To do that, we have to pass in the task_struct of the task which
will own the ipc_ns, so we can assign its user_ns.
Changelog:
Feb 23: As per Oleg comment, just pass in tsk. To get the
ipc_ns from the nsproxy we need to include nsproxy.h
Signed-off-by: Serge E. Hallyn
Convert macros to functions to let type safety do its thing. Switch
some functions from ints to more appropriate bool. Move all forward
declarations together to top of the #ifdef __KERNEL__ section. Use
kernel-doc format for comments.
Some macros couldn't be converted because they use
Quoting Andrew Morton (a...@linux-foundation.org):
On Thu, 17 Feb 2011 15:03:33 +
Serge E. Hallyn se...@hallyn.com wrote:
ptrace is allowed to tasks in the same user namespace according to
the usual rules (i.e. the same rules as for two tasks in the init
user namespace). ptrace is
On Wed, 23 Feb 2011 19:10:33 -0500
Vivek Goyal vgo...@redhat.com wrote:
On Thu, Feb 24, 2011 at 12:14:11AM +0100, Andrea Righi wrote:
On Wed, Feb 23, 2011 at 10:23:54AM -0500, Vivek Goyal wrote:
Agreed. Granularity of per inode level might be accetable in many
cases. Again, I am
Quoting Andrew Morton (a...@linux-foundation.org):
On Thu, 17 Feb 2011 15:03:25 +
Serge E. Hallyn se...@hallyn.com wrote:
/*
+ * called with RCU read lock from check_kill_permission()
+ */
+static inline int kill_ok_by_cred(struct task_struct *t)
+{
+ const struct cred *cred
same_or_ancestore_user_ns() was not an appropriate check to
constrain cap_issubset. Rather, cap_issubset() only is
meaningful when both capsets are in the same user_ns.
Signed-off-by: Serge E. Hallyn serge.hal...@canonical.com
---
include/linux/user_namespace.h |9 -
On Thu, 24 Feb 2011 00:48:18 +
Serge E. Hallyn se...@hallyn.com wrote:
Quoting Andrew Morton (a...@linux-foundation.org):
On Thu, 17 Feb 2011 15:03:25 +
Serge E. Hallyn se...@hallyn.com wrote:
/*
+ * called with RCU read lock from check_kill_permission()
+ */
+static
On Wed, Feb 23, 2011 at 4:40 PM, KAMEZAWA Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
On Wed, 23 Feb 2011 19:10:33 -0500
Vivek Goyal vgo...@redhat.com wrote:
On Thu, Feb 24, 2011 at 12:14:11AM +0100, Andrea Righi wrote:
On Wed, Feb 23, 2011 at 10:23:54AM -0500, Vivek Goyal wrote:
Quoting Andrew Morton (a...@linux-foundation.org):
On Thu, 24 Feb 2011 00:49:01 +
Serge E. Hallyn se...@hallyn.com wrote:
same_or_ancestore_user_ns() was not an appropriate check to
constrain cap_issubset. Rather, cap_issubset() only is
meaningful when both capsets are in the same
On Thu, 24 Feb 2011 03:24:16 + Serge E. Hallyn se...@hallyn.com wrote:
Quoting Andrew Morton (a...@linux-foundation.org):
On Thu, 17 Feb 2011 15:04:07 +
Serge E. Hallyn se...@hallyn.com wrote:
There's a fairly well adhered to convention that global symbols (and
often static
* Andrea Righi ari...@develer.com [2011-02-22 18:12:51]:
Currently the blkio.throttle controller only support synchronous IO requests.
This means that we always look at the current task to identify the owner of
each IO request.
However dirty pages in the page cache can be wrote to disk
Casey Schaufler ca...@schaufler-ca.com writes:
On 2/23/2011 12:55 PM, Eric W. Biederman wrote:
Casey Schaufler ca...@schaufler-ca.com writes:
I confess that I remain less well educated on namespaces than
I probably should be, but with what I do know it seems that the
relationships between
36 matches
Mail list logo
