"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
>> From: Miklos Szeredi <[EMAIL PROTECTED]>
>>
>> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
>> unshare(2), then allow user mounts within the new namespace.
>>
>> This is not flexible
On Thu, Apr 12, 2007 at 03:32:08PM -0500, Serge E. Hallyn wrote:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
> > unshare(2), then allow user mounts within the new namespace.
> >
This is a note to let you know that I've just added the patch titled
Subject: kobject: Comment and warning fixes to kobject.c
to my gregkh-2.6 tree. Its filename is
kobject-comment-and-warning-fixes-to-kobject.c.patch
This tree can be found at
http://www.kernel.org/pub/linux/ke
Andrew Morton wrote:
On Wed, 11 Apr 2007 19:02:27 +0400
Pavel Emelianov <[EMAIL PROTECTED]> wrote:
Provides a per-container statistics concerning the numbers of tasks
in various states, system and user times, etc. Patch is inspired
by Paul's example of the used CPU time accounting. Although thi
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
> unshare(2), then allow user mounts within the new namespace.
>
> This is not flexible enough, because user mounts can't be enabled for
> the
On Thu, Apr 12, 2007 at 07:56:47PM +0200, Herbert Poetzl wrote:
> > - Each task-group gets its own runqueue on every cpu.
>
> how does that scale for, let's say 200-300 guests on a
> 'typical' dual CPU machine?
Scheduling complexity is still O(1) and hence I would say CPU-wise, it
should
On Thu, Apr 12, 2007 at 11:21:11PM +0530, Srivatsa Vaddagiri wrote:
> - Real-time tasks - Should be left alone as they are today?
> i.e real time tasks across groups should be scheduled as if
> they are in same group
This patchset doesnt handle this requirement (yet). Will ha
On Thu, Apr 12, 2007 at 11:21:11PM +0530, Srivatsa Vaddagiri wrote:
> Here's a respin of my earlier CPU controller to work on top of Paul
> Menage's process container patches.
>
> Problem:
>
> Current CPU scheduler is very task centric, which makes it
> difficult to manage cpu resourc
This patch registers cpu controller as a subsystem in process container
patches.
How to use the controller:
1. Apply these patches first on top of 2.6.20 kernel
http://lkml.org/lkml/2007/4/6/301
http://lkml.org/lkml/2007/4/6/300
http://marc
We rely very much on task_cpu(p) to be correct at all times, so that we can
correctly find the task_grp_rq from which the task has to be removed or added
to.
There is however one place in the scheduler where this assumption of
task_cpu(p) being correct is broken. This patch fixes that piece of co
When balancing tasks across CPU runqueues, we need to take into account the
quota of task-groups (for example: we dont want to pull all tasks of a group
with 90% limit on the same CPU).
This is easily accomplished by piggy backing on the smpnice mechanism.
This patch also modifies move_tasks()
Deal with task-groups whose bandwidth hasnt been explicitly set by the
administrator. Unallocated CPU bandwidth is equally distributed among such
"don't care" groups.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
linux-2.6.18-root/include/linux/sched.h |2
---
1 file changed, 9
When a task moves between groups (as initiated by an administrator), it has to
be removed from the runqueue of its old group and added to the runqueue of its
new group. This patch defines this move operation.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
1 file changed, 28 insertions(
Define these operations for a task-group:
- create new group
- destroy existing group
- set bandwidth (quota) for a group
- get bandwidth (quota) of a group
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
1 file changed, 71 insertions(+)
---
diff -pu
This patch does the actual job of dividing up CPU time amonmg various
task-groups as per their quota.
High-level overview:
Lets say that we have three task-groups/classes A, B and C
whose quota is 50%, 30% and 20%. The quota specifies how
much of execution time each group
To retain good interactivity, priority of a task-group is defined to be the
same as the priority of the highest-priority runnable task it has in its
runqueue.
This means as tasks come and go, priority of a task-group can change.
This patch deals with such changes to task-group priority.
P.S :
This patch introduces a new runqueue structure (struct task_grp_rq) which is
used to hold "related" tasks together. The structure is quite similar to how
the runqueue structure looks today.
The scheme is every task group will have its own per-cpu runqueues (which is
of type 'struct task_grp_rq'
Here's a respin of my earlier CPU controller to work on top of Paul
Menage's process container patches.
Problem:
Current CPU scheduler is very task centric, which makes it
difficult to manage cpu resource consumption of a group of
(related) tasks.
For ex: with the
From: Miklos Szeredi <[EMAIL PROTECTED]>
Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
FUSE was designed from the beginning to be safe for unprivileged
users. This has also been verified in practice over many years. And
unprivileged fuse mounts still require a private namespace with us
From: Miklos Szeredi <[EMAIL PROTECTED]>
Define a new fs flag FS_SAFE, which denotes, that unprivileged
mounting of this filesystem may not constitute a security problem.
Since most filesystems haven't been designed with unprivileged
mounting in mind, a thorough audit is needed before setting thi
From: Miklos Szeredi <[EMAIL PROTECTED]>
Declarations go into headers.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/super.c
===
--- linux.orig/fs/super.c 2007-04-12 13:26:42.0 +0200
+++ linux/f
From: Miklos Szeredi <[EMAIL PROTECTED]>
Allow bind mounts to unprivileged users if the following conditions
are met:
- user mounts are permitted in the current mount namespace
- mountpoint is not a symlink or special file
- mountpoint is not a sticky directory or is owned by the current us
From: Miklos Szeredi <[EMAIL PROTECTED]>
Allow clone_mnt() to return errors other than ENOMEM. This will be
used for returning a different error value when the number of user
mounts goes over the limit.
Fix copy_tree() to return EPERM for unbindable mounts.
Don't propagate further from dup_mnt_
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting the "permit user mount in
namespace" flag will also be needed.
Signe
From: Miklos Szeredi <[EMAIL PROTECTED]>
If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
unshare(2), then allow user mounts within the new namespace.
This is not flexible enough, because user mounts can't be enabled for
the initial namespace.
The remaining clone bits also getting
From: Miklos Szeredi <[EMAIL PROTECTED]>
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having "user=UID" option in
/etc/mtab. The difference is that umount also checks /etc/fstab,
presumably to exclude another mount on the same mountpoint.
From: Miklos Szeredi <[EMAIL PROTECTED]>
Add ownership information to mounts.
A new mount flag, MS_SETUSER is used to make a mount owned by a user.
If this flag is specified, then the owner will be set to the current
real user id and the mount will be marked with the MNT_USER flag. On
remount do
From: Miklos Szeredi <[EMAIL PROTECTED]>
If MNT_NS_PERMIT_USERMOUNTS flag is not set for the current namespace,
then unprivileged mounts will be denied.
By default this flag is cleared in all namespaces.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/namespace.c
=
This patchset adds support for keeping mount ownership information in
the kernel, and allow unprivileged mount(2) and umount(2) in certain
cases.
This can be useful for the following reasons:
- mount(8) can store ownership ("user=XY" option) in the kernel
instead, or in addition to storing it i
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Wed, 2007-04-11 at 14:54 -0600, Eric W. Biederman wrote:
>> When someone mentions a pid which side of the above statement are you
>> thinking of the left hand side or the right hand side. The type or
>> the variable name.
>
> Traditionally, I think o
Andrew Morton wrote:
> On Wed, 11 Apr 2007 19:02:27 +0400
> Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>
>> Provides a per-container statistics concerning the numbers of tasks
>> in various states, system and user times, etc. Patch is inspired
>> by Paul's example of the used CPU time accounting.
Serge E. Hallyn wrote:
> Quoting Kirill Korotaev ([EMAIL PROTECTED]):
>
>>>Kirill,
>>>
>>>We are working on getting a few UTS namespace tests included in Linux
>>>Testsuite Project (LTP) and were wondering if you (or anyone else) had
>>>any test cases for IPC namespace.
>>>
>>>If there are tests
Quoting Kirill Korotaev ([EMAIL PROTECTED]):
> > Kirill,
> >
> > We are working on getting a few UTS namespace tests included in Linux
> > Testsuite Project (LTP) and were wondering if you (or anyone else) had
> > any test cases for IPC namespace.
> >
> > If there are tests for IPC NS, can you s
> Kirill,
>
> We are working on getting a few UTS namespace tests included in Linux
> Testsuite Project (LTP) and were wondering if you (or anyone else) had
> any test cases for IPC namespace.
>
> If there are tests for IPC NS, can you share those tests with us ?
> And, do you have any plans to
34 matches
Mail list logo
