Balbir Singh wrote:
This patch is inspired by the discussion at http://lkml.org/lkml/2007/4/11/187
and implements per container statistics as suggested by Andrew Morton
in http://lkml.org/lkml/2007/4/11/263. The patch is on top of 2.6.21-mm1
with Paul's containers v9 patches (forward ported)
Kirill Korotaev wrote:
oh, please no... Andrew, this loop can be very very long when having 10,000
tasks on the machine...
we have had enough such issues in OpenVZ and just don't want to come through
this again.
Also sum of RUNNING + UNINTERRUPTIBLE is required for per-container loadavg
The set of functions process_session, task_session, process_group
and task_pgrp is confusing, as the names can be mixed with each other
when looking at the code for a long time.
The proposals are to
* equip the functions that return the integer with _nr suffix to
represent that fact,
* and to
Hello, All!
I have run LTP over NFSv3 with O_DIRECT support with the default mount
options:
artemis ~/src/linux-2.6.21.1 $ cat /proc/mounts | fgrep nfs
192.168.1.9:/home/den/tmp /mnt nfs
rw,vers=3,rsize=131072,wsize=131072,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.1.9
0 0
artemis
Andrew,
I've fixed a number of issues in i2o layer:
[patch i2o 1/6] i2o_cfg_passthru cleanup (memory leak and infinite loop)
[patch i2o 2/6] wrong memory access in i2o_block_device_lock()
[patch i2o 3/6] i2o message leak in i2o_msg_post_wait_mem()
[patch i2o 4/6] i2o proc reading oops
[patch i2o
This patch fixes access to memory that has not been allocated:
i2o_msg_get_wait() can returns errors different from I2O_QUEUE_EMPTY. But the
result is checked only against this code. If it is not I2O_QUEUE_EMPTY then we
dereference the error code as the pointer later.
Signed-off-by: Vasily Averin
We need to free i2o msg in case of error.
Signed-off-by: Vasily Averin [EMAIL PROTECTED]
--- lk2.6/drivers/message/i2o/exec-osm.c
+++ lk2.6/drivers/message/i2o/exec-osm.c
@@ -131,8 +131,10 @@ int i2o_msg_post_wait_mem(struct i2o_con
int rc = 0;
wait = i2o_exec_wait_alloc();
-
fixed oops on reading from some i2o proc files (i2o_seq_show_driver_store() and
other) because their handlers uses exec field in struct i2o_controller
Signed-off-by: Vasily Averin [EMAIL PROTECTED]
--- lk2.6/drivers/message/i2o/exec-osm.c
+++ lk2.6/drivers/message/i2o/exec-osm.c
@@ -339,6
Reading from some i2o related proc files can lead to the i2o controller hang due
unknown reasons. As a workaround this patch changes the permission of these
files to root-only accessible.
Signed-off-by: Vasily Averin [EMAIL PROTECTED]
--- lk2.6/drivers/message/i2o/i2o_proc.c
+++
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
The set of functions process_session, task_session, process_group
and task_pgrp is confusing, as the names can be mixed with each other
when looking at the code for a long time.
The proposals are to
* equip the functions that return the integer
I would add:
I've reported about this issue some time ago to [EMAIL PROTECTED]
How this lockup can be reproduced:
- boot the kernel,
- load i2o_proc module
- login as user and read all entries in /proc/i2o/ directory
My testnode hangs when I try to read any file from /proc/i2o/iop0/030/
On Tue, 15 May 2007 16:48:16 +0400
Vasily Averin [EMAIL PROTECTED] wrote:
fixed output of i2o debug messages, extra KERN_ are removed
Otherwise looks good. ACK apart from the interesting goto targets and
the /proc handling.
___
Devel mailing list
- cleanup:
+cleanup:
kfree(reply);
+ if (msg)
+out:
+ i2o_msg_nop(c, msg);
Put the label before the if. Much saner that way
kfree(reply);
+ if (msg)
+out:
+ i2o_msg_nop(c, msg);
return rcode;
Ditto
Alan Cox wrote:
On Tue, 15 May 2007 16:47:05 +0400
Vasily Averin [EMAIL PROTECTED] wrote:
Reading from some i2o related proc files can lead to the i2o controller hang
due
unknown reasons. As a workaround this patch changes the permission of these
files to root-only accessible.
I guess
14 matches
Mail list logo
