On Sun, Aug 24, 2008 at 11:28:14PM -0400, Oren Laadan wrote:
Louis Rilling wrote:
On Wed, Aug 20, 2008 at 11:07:16PM -0400, Oren Laadan wrote:
Dump the files_struct of a task with 'struct cr_hdr_files', followed by
all open file descriptors. Since FDs can be shared, they are assigned a
tag
On Fri, 2008-08-22 at 14:55 -0400, Vivek Goyal wrote:
As an aside, when the IO context of a certain IO operation is known
(synchronous IO comes to mind) I think it should be cashed in the
resulting bio so that we can do without the expensive accesses to
bio_cgroup once it enters
Eelco Chaudron wrote:
Hi Dave,
Guess it's useful when you are interested in network statistics per name
space. I'm currently evaluating how much of the name space implementation we
could use in one of our projects (see my other email to the group).
Any idea who might have a complete
Quoting Li Zefan ([EMAIL PROTECTED]):
During the use of a dev_cgroup, we should guarantee the corresponding
cgroup won't be deleted (i.e. via rmdir). This can be done through
css_get(dev_cgroup-css), but here we can just get and use the
dev_cgroup under rcu_read_lock.
And also remove
Quoting Li Zefan ([EMAIL PROTECTED]):
This saves 40 bytes on my x86_32 box.
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Acked-by: Serge Hallyn [EMAIL PROTECTED]
---
security/device_cgroup.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git
Quoting Li Zefan ([EMAIL PROTECTED]):
Signed-off-by: Li Zefan [EMAIL PROTECTED]
Yup.
Acked-by: Serge Hallyn [EMAIL PROTECTED]
thanks,
-serge
---
security/device_cgroup.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/security/device_cgroup.c
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
Quoting Ian Kent ([EMAIL PROTECTED]):
On Fri, 2008-08-08 at 09:58 -0500, Serge E. Hallyn wrote:
Quoting Ian Kent ([EMAIL PROTECTED]):
On Fri, 2008-08-08 at 11:48 +0800, Ian Kent wrote:
Please remind me again why autofs's
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
It definately seems to make sense in terms of the security
implications. And solving this before the filesystem handlers seems
to make sense too. Although I would like to get the first 3 patches
init_dev() is doing too many things all in one function, making it
harder to understand/extend. This and following two patches attempt
to simplify/cleanup the interface a bit.
Only touch tested at this point. Appreciate any comments :-)
---
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject:
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 2/3] Move some init_dev() code to callers
init_dev() tries to find a tty and if it finds an existing tty, does
a 'fast' open. If its not an existing tty, init_dev does a slower
first time open requiring allocation and complex
From: Sukadev Bhattiprolu [EMAIL PROTECTED]
Subject: [RFC][PATCH 3/3] Rename and change init_dev() prototype
init_dev() takes an additional '*ret_tty' parameter so it can either return
a valid 'tty_struct *' (on success) or an integer error code on failure.
Drop the '*ret_tty' and return either
On Mon, 25 Aug 2008 13:11:10 -0700
[EMAIL PROTECTED] wrote:
init_dev() is doing too many things all in one function, making it
harder to understand/extend. This and following two patches attempt
to simplify/cleanup the interface a bit.
Only touch tested at this point. Appreciate any
[EMAIL PROTECTED] wrote:
By extension, maybe the tty layer would need another interface to determine
the instance:
instance = driver-ops-get_instance(driver, inode, other_stuff)
using this we find the tty
tty = driver-ops-something(driver, instance, idx);
This seems
This seems more than a bit redundant. The instance, IMO, *is* the tty
structure; so the interface should be:
Only for a re-open - which is very different to an initial open,
and /dev/tty is deep magic in this situation.
Not index, but inode. If, as a courtesy to the generic driver, we
H. Peter Anvin [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
By extension, maybe the tty layer would need another interface to
determine
the instance:
instance = driver-ops-get_instance(driver, inode, other_stuff) using
this we find the tty
tty =
Alan Cox wrote:
This seems more than a bit redundant. The instance, IMO, *is* the tty
structure; so the interface should be:
Only for a re-open - which is very different to an initial open,
and /dev/tty is deep magic in this situation.
I guess I fail to understand something here, perhaps
[EMAIL PROTECTED] wrote:
tty = driver-ops-get_tty(driver, inode [, other_stuff?]);
Can the inode be used to identify the driver too ? (but inode to driver
mapping is not trivial atm).
It can, but it's an O(n) operation in the number of registered drivers.
However, we can only call
H. Peter Anvin [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
tty = driver-ops-get_tty(driver, inode [, other_stuff?]);
Can the inode be used to identify the driver too ? (but inode to driver
mapping is not trivial atm).
It can, but it's an O(n) operation in the number of registered
[EMAIL PROTECTED] wrote:
Yes, we know the driver, but do we need to pass it into -get_tty() ?
Passing it in (or having the operation compute from inode) has advantage
of allowing drivers to share code if necessary.
Yes, and it gets access to its own data. It's how you implement an
On Mon, Aug 25, 2008 at 6:47 PM, Lai Jiangshan [EMAIL PROTECTED] wrote:
In original code, we kmalloc a lot of memory when we open cgroup.tasks.
_This memory is allocated by kmalloc_, So this memory is not statistical
for this process or this user. This is a critical bug.
It's true that this
20 matches
Mail list logo
