[Devel] Re: [patch i2o 5/6] i2o_proc files permission

2007-05-15 Thread Vasily Averin
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.

[Devel] Re: [patch i2o 5/6] i2o_proc files permission

2007-05-15 Thread Alan Cox
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

[Devel] Re: [patch i2o 6/6] i2o debug output cleanup

2007-05-15 Thread Alan Cox
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

[Devel] Re: [patch i2o 1/6] i2o_cfg_passthru cleanup

2007-05-15 Thread Alan Cox
> - 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 ___

Re: [Devel] [patch i2o 5/6] i2o_proc files permission

2007-05-15 Thread Vasily Averin
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:

[Devel] Re: [PATCH] Brush up task's session and group numbers manipulations

2007-05-15 Thread Serge E. Hallyn
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

Re: [Devel] [patch i2o] i2o layer cleanup

2007-05-15 Thread Kirill Korotaev
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

[Devel] [patch i2o 6/6] i2o debug output cleanup

2007-05-15 Thread Vasily Averin
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)

[Devel] [patch i2o 5/6] i2o_proc files permission

2007-05-15 Thread Vasily Averin
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

[Devel] [patch i2o 4/6] i2o proc reading oops

2007-05-15 Thread Vasily Averin
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

[Devel] [patch i2o 3/6] i2o message leak in i2o_msg_post_wait_mem()

2007-05-15 Thread 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(); -

[Devel] [patch i2o 2/6] wrong memory access in i2o_block_device_lock()

2007-05-15 Thread Vasily Averin
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

[Devel] [patch i2o 1/6] i2o_cfg_passthru cleanup

2007-05-15 Thread 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

[Devel] [patch i2o] i2o layer cleanup

2007-05-15 Thread Vasily Averin
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

[Devel] NFSv3 client OOPS during LTP test

2007-05-15 Thread Denis V. Lunev
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 ~/

[Devel] [PATCH] Brush up task's session and group numbers manipulations

2007-05-15 Thread Pavel Emelianov
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

[Devel] Re: [RFC][PATCH] Per container statistics

2007-05-15 Thread Balbir Singh
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

[Devel] Re: [RFC][PATCH] Per container statistics

2007-05-15 Thread Kirill Korotaev
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