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.
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 you have a crap
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 li
> - 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
___
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/
directory:
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 inte
Acked-By: Kirill Korotaev <[EMAIL PROTECTED]>
Vasily Averin wrote:
> 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 l
fixed output of i2o debug messages, extra KERN_ are removed
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- lk2.6/drivers/message/i2o/debug.c
+++ lk2.6/drivers/message/i2o/debug.c
@@ -24,7 +24,7 @@ void i2o_report_status(const char *sever
if (cmd == I2O_CMD_UTIL_EVT_REGISTER)
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
+++ lk2.6/drivers/m
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 +3
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();
-
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
This patch fixes a number of issues in i2o_cfg_passthru{,32}:
- i2o_msg_get_wait() return vaile is not checked;
- i2o_message memory leaks on error paths;
- infinite loop to sg_list_cleanup in passthru32
it's important issue because of i2o_cfg_passthru is used by raidutils for
monitorig controller
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 5
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 ~/
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 ma
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 loada
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
18 matches
Mail list logo