Andrew Morton wrote:
> On Fri, 08 Jun 2007 07:51:12 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> I'd have hoped to see containerstats.c in here.
>>>
>> The current statistics code is really small, so it fit into taskstats.c.
>> May be in the future, we could re-facto
On Fri, 08 Jun 2007 07:51:12 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >
> > I'd have hoped to see containerstats.c in here.
> >
>
> The current statistics code is really small, so it fit into taskstats.c.
> May be in the future, we could re-factor it and move it ou
On 6/7/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> this needs tasklist_lock?
>
rcu_read_lock() should be fine. From Eric's patch at
2.6.17-mm2 - proc-remove-tasklist_lock-from-proc_pid_readdir.patch
The patch mentions that "We don't need the tasklist_lock to safely
iterate through processes
Andrew Morton wrote:
>
> I'd have hoped to see containerstats.c in here.
>
The current statistics code is really small, so it fit into taskstats.c.
May be in the future, we could re-factor it and move it out.
>> +#ifndef _LINUX_CONTAINERSTATS_H
>> +#define _LINUX_CONTAINERSTATS_H
>> +
>> +#incl
On Wed, 6 Jun 2007 17:28:13 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> Hi, Andrew/Paul,
>
> Here's the latest version of containerstats ported to v10. Could you
> please consider it for inclusion
>
> Changelog
>
> 1. Instead of parsing long container path's use the dentry to match the
>
On Thu, 07 Jun 2007 16:51:50 +0400 Pavel Emelianov wrote:
> If the kernel OOPSed or BUGed then it probably should
> be considered as tainted. Thus, all subsequent OOPSes
> and SysRq dumps will report the tainted kernel. This
> saves a lot of time explaining oddities in the calltraces.
>
> The p
> > The set of people using exclusive cpusets is roughly some subset of
> > those running multiple, cpuset isolated, non-cooperating jobs on big
> > iron, usually with the aid of a batch scheduler.
>
> Unfortunately I would imagine these users to be very intereseted in
> providing checkpoint/resta
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > For /cpusets/set0/set1 to have cpu 1 exclusively, does /cpusets/set0
> > also have to have it exclusively?
>
> Yes.
>
> > If so, then clearly this approach won't work, since if any container has
> > exclusive cpus, then every container will have sibli
> For /cpusets/set0/set1 to have cpu 1 exclusively, does /cpusets/set0
> also have to have it exclusively?
Yes.
> If so, then clearly this approach won't work, since if any container has
> exclusive cpus, then every container will have siblings with exclusive
> cpus, and unshare still isn't possi
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > I suppose as a cleaner alternative we could
> > add a container_subsys->inherit_defaults() handler, to be called at
> > container_clone(), and for cpusets this would set cpus and mems to
> > the parent values - sibling exclusive values. If that comes
On 6/7/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
when there's no tasks in a container, opening
//tasks
spits the following warning because we are trying to
kmalloc(0).
I guess I'm not opposed to this change - but isn't there still
discussion going on about whether kmalloc(0) should act
Pavel Emelianov wrote:
Hmm... The loopback must be doing bad things then. It first calls
eth_type_trans and then accounts for the new skb->len.
Perhaps it should be changed. e100 calculates the entire
frame as far as I can tell, and e1000 and tg3 do it in hardware
(not sure what all they are
From: Dave Hansen <[EMAIL PROTECTED]>
Some ioctl()s can cause writes to the filesystem. Take
these, and make them use mnt_want/drop_write() instead.
We need to pass the filp one layer deeper in XFS, but
somebody _just_ pulled it out in February because nobody
was using it, so I don't feel guilty
From: Dave Hansen <[EMAIL PROTECTED]>
Christoph H. says this stands on its own and can go in before the
rest of the r/o bind mount set.
Some filesystems forego the vfs and may_open() and create their
own 'struct file's.
This patch creates a couple of helper functions which can be
used by these
From: Dave Hansen <[EMAIL PROTECTED]>
chown/chmod,etc... don't call permission in the same way
that the normal "open for write" calls do. They still
write to the filesystem, so bump the write count during
these operations.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/open.c | 41
Ben Greear wrote:
> Pavel Emelianov wrote:
>> Ben Greear wrote:
>>
>>> Pavel Emelianov wrote:
>>>
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
On Thu, 07 Jun 2007 15:16:34 +0400
Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> The usage is
> # ip link add [name] type veth [peer ] [mac ] [peer_mac ]
>
> This version doesn't include the fix for ip/iplink.c as Patrick
> said that he had included it into his patches already.
>
> Signed-off-by:
From: Dave Hansen <[EMAIL PROTECTED]>
This also creates a little helper in the NFS code to
make an if() a little bit less ugly.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/namei.c|4
fs/nfsd/vfs.c | 23 +++
2 files changed, 23 insertions(+), 4 de
From: Dave Hansen <[EMAIL PROTECTED]>
ext4_change_inode_journal_flag() is only called from one
location: ext4_ioctl(EXT3_IOC_SETFLAGS). That ioctl
case already has a IS_RDONLY() call in it so this one
is superfluous.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/ext4/inode.c |2
From: Dave Hansen <[EMAIL PROTECTED]>
This is the first really tricky patch in the series. It
elevates the writer count on a mount each time a
non-special file is opened for write.
This is not completely apparent in the patch because the
two if() conditions in may_open() above the
mnt_want_write
From: Dave Hansen <[EMAIL PROTECTED]>
Some ioctls need write access, but others don't. Make a helper
function to decide when write access is needed, and take it.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/ncpfs/ioctl.c | 55 +
From: Dave Hansen <[EMAIL PROTECTED]>
This takes care of all of the direct callers of vfs_mknod().
Since a few of these cases also handle normal file creation
as well, this also covers some calls to vfs_create().
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
fs/namei.c | 12 +
From: Dave Hansen <[EMAIL PROTECTED]>
This basically audits the callers of xattr_permission(), which
calls permission() and can perform writes to the filesystem.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/nfsd/nfs4proc.c |7 ++-
fs/xattr.c | 16 ++--
From: Dave Hansen <[EMAIL PROTECTED]>
This patch adds two function mnt_want_write() and
mnt_drop_write(). These are used like a lock pair around
and fs operations that might cause a write to the filesystem.
Before these can become useful, we must first cover each
place in the VFS where writes ar
From: Dave Hansen <[EMAIL PROTECTED]>
These should have been documented from the beginning. Fix it.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
include/linux/fs.h | 27 +++
1 file changed, 27 insertions(+)
Index: 2.6.22-rc4-mm2-robindmount/include/linux/fs
From: Dave Hansen <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
fs/nfs/dir.c |3 ++-
fs/nfsd/vfs.c |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
Index: 2.6.22-rc4-mm2-robindmount/fs/nfs/dir.c
=
From: Dave Hansen <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/namei.c |4
ipc/mqueue.c |5 -
2 files changed, 8 insertions(+), 1 deletion(-)
Index: 2.6.22-rc4-mm2-robindmount/fs/namei.c
From: Dave Hansen <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
fs/utimes.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
Index: 2.6.22-rc4-mm2-robindmount/fs/utimes.c
===
--- 2.6.22-
From: Cedric Le Goater <[EMAIL PROTECTED]>
Signed-off-by: Cedric Le Goater <[EMAIL PROTECTED]>
---
include/linux/fs.h|9 +
include/linux/mount.h | 11 ---
2 files changed, 9 insertions(+), 11 deletions(-)
Index: 2.6.22-rc4-mm2-robindmount/include/linux/fs.h
From: Dave Hansen <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/open.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
Index: 2.6.22-rc4-mm2-robindmount/fs/open.c
===
--- 2.6
From: Dave Hansen <[EMAIL PROTECTED]>
elevate mnt writers for callers of vfs_mkdir()
Pretty self-explanatory. Fits in with the rest of the series.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/namei.c|5 +
fs/nfsd/nfs4recover.c |4
2 files changed, 9 i
From: Dave Hansen <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
net/unix/af_unix.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
Index: 2.6.22-rc4-mm2-robindmount/net/unix/af_unix.c
From: Dave Hansen <[EMAIL PROTECTED]>
ext3_change_inode_journal_flag() is only called from one
location: ext3_ioctl(EXT3_IOC_SETFLAGS). That ioctl
case already has a IS_RDONLY() call in it so this one
is superfluous.
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/ext3/inode.c |2
Hi,
This is a refreshed version of dave's r/o bind mount patchset
on a 2.6.22-rc4-mm2.
C.
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Dev
From: Dave Hansen <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/namei.c | 10 ++
1 file changed, 10 insertions(+)
Index: 2.6.22-rc4-mm2-robindmount/fs/namei.c
===
--- 2.6.22-rc4-mm2-robindm
From: Dave Hansen <[EMAIL PROTECTED]>
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
---
---
fs/inode.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: 2.6.22-rc4-mm2-robindmount/fs/inode.c
===
--- 2.6.22-rc4-
From: Dave Hansen <[EMAIL PROTECTED]>
It is OK to let access() go without using a mnt_want/drop_write()
pair because it doesn't actually do writes to the filesystem,
and it is inherently racy anyway. This is a rare case when it is
OK to use __mnt_is_readonly() directly.
Signed-off-by: Dave Hanse
Pavel Emelianov wrote:
Ben Greear wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver k
Pavel Emelianov wrote:
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the de
Ben Greear wrote:
> Pavel Emelianov wrote:
>> Veth stands for Virtual ETHernet. It is a simple tunnel driver
>> that works at the link layer and looks like a pair of ethernet
>> devices interconnected with each other.
>>
> As Dave mentioned, there is already a driver known as 'veth'. Maybe borr
>>
>> no one is against generic code and ability to create 2 interfaces in
>> *one* namespace.
>> (Like we currently allow to do so in OpenVZ)
>>
>> However, believe me, moving an interface is a *hard* operation. Much
>> harder then netdev
>> register from the scratch.
>>
>> Because it requires to
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow
the etun name as well?
I wo
Daniel Lezcano wrote:
> Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device
Kirill Korotaev wrote:
Deniel,
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But
Deniel,
Daniel Lezcano wrote:
> Pavel Emelianov wrote:
>
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the other namespace the RTNL_NEWLINK
me
Hello Paul !
[EMAIL PROTECTED] wrote:
> This patch adds the per-directory "tasks" file for containerfs mounts;
> this allows the user to determine which tasks are members of a
> container by reading a container's "tasks", and to move a task into a
> container by writing its pid to its "tasks".
he
If the kernel OOPSed or BUGed then it probably should
be considered as tainted. Thus, all subsequent OOPSes
and SysRq dumps will report the tainted kernel. This
saves a lot of time explaining oddities in the calltraces.
The previous version was buggy and reported the kernel
to be tainted at the
The usage is
# ip link add [name] type veth [peer ] [mac ] [peer_mac ]
This version doesn't include the fix for ip/iplink.c as Patrick
said that he had included it into his patches already.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff --git a/ip/Makefile b/ip/Makefile
index 9a5bf
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces
but it can be used as is as well.
Eric recently sent a similar driver c
>> I did this at the very first version, but Alexey showed me that this
>> would be wrong. Look. When we create the second device it must be in
>> the other namespace as it is useless to have them in one namespace.
>> But if we have the device in the other namespace the RTNL_NEWLINK
>> message from
Vasily Averin wrote:
Customers claims to ext3-related errors, investigation showed that ext3 orphan
list has been corrupted and have the reference to non-ext3 inode. The following
debug helps to understand the reasons of this issue.
This looks like it might be related to the -as far as I recall-
Vasily Averin wrote:
After ext3 orphan list check has been added into ext3_destroy_inode() (please
see my previous patch) the following situation has been detected:
EXT3-fs warning (device sda6): ext3_unlink: Deleting nonexistent file
(37901290), 0
Inode 0101a15b7840: orphan list check fa
Vasily Averin wrote:
Customers claims to ext3-related errors, investigation showed that ext3 orphan
list has been corrupted and have the reference to non-ext3 inode. The following
debug helps to understand the reasons of this issue.
Vasily, does your customer have this patch in place?
http:/
David Miller wrote:
From: Kirill Korotaev <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 12:14:29 +0400
David Miller wrote:
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer
Pavel Emelianov wrote:
Patrick McHardy wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network nam
From: Kirill Korotaev <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 12:14:29 +0400
> David Miller wrote:
> > From: Pavel Emelianov <[EMAIL PROTECTED]>
> > Date: Wed, 06 Jun 2007 19:11:38 +0400
> >
> >
> >>Veth stands for Virtual ETHernet. It is a simple tunnel driver
> >>that works at the link laye
David Miller wrote:
> From: Pavel Emelianov <[EMAIL PROTECTED]>
> Date: Wed, 06 Jun 2007 19:11:38 +0400
>
>
>>Veth stands for Virtual ETHernet. It is a simple tunnel driver
>>that works at the link layer and looks like a pair of ethernet
>>devices interconnected with each other.
>
>
> I would s
Patrick McHardy wrote:
> Pavel Emelianov wrote:
>> Veth stands for Virtual ETHernet. It is a simple tunnel driver
>> that works at the link layer and looks like a pair of ethernet
>> devices interconnected with each other.
>>
>> Mainly it allows to communicate between network namespaces but
>> it c
59 matches
Mail list logo
