[Discussion] a bug of web100 patch (for Linux 2.6.13) for non-i386 architecture?

["Xiaoliang (David) Wei" <weixl@xxxxxxxxxxx>]

Hi,
    I have some troubles with web100 patch for Linux 2.6.13 (I also saw the 
same problem for Linux 2.6.12). Here is the details, my understanding, and a 
proposed solution:

    I am using a SunFire server with two 64bits CPU (AMD Opteron(tm) 
Processor 250). This is an x86_64 system.
    After I patched the web100 to a Linux 2.6.13.2 kernel, the system runs 
well. However, when we do "ls /proc/web100/<id>". "ls" failed with a segment 
fault error. Even worse, when we do "cat /proc/sys/net/ipv4/web100_fperms" 
or "cat /proc/sys/net/ipv4/web100_gid", we got kernel-panic.

    I read the code of  fs/proc/web100.c. The error point of "ls 
/proc/web100/<id>" is in the loop structure of "connection_dir_readdir" 
function:
               p = &web100_file_arr[i];
               while (p->name) {
                       ...
                       p++;
               }
   p->name is not necessary 0 at the end of the web100_file_arr, if the 
architecture is not i686.
   The similar problem is in "web100_proc_dointvec_update" function which 
causes the kernel panic of "cat /proc/sys/net/ipv4/web100_fperm":
                for (p = &web100_file_arr[0]; p->name; p++) {
                       ...
                }

   So, It seems that we need to change the definition of web100_file_arr as 
follows to ensure the validity of the p->name conditions:
--------------------------------------------
define F(name,ino,perm) { sizeof (name) - 1, (name), (ino), (perm), NULL }
static struct web100_file web100_file_arr[] = {
       F("spec-ascii", PROC_CONN_SPEC_ASCII, S_IFREG | S_IRUGO),
       F("spec", PROC_CONN_SPEC, S_IFREG | S_IRUGO),
       F("read", PROC_CONN_READ, 0),
       F("test", PROC_CONN_TEST, 0),
       F("tune", PROC_CONN_TUNE, 0),
+        {0, NULL, 0, 0, NULL }  //add this as the end of the array for 
safety of p->name conditions by David Wei (weixl@xxxxxxxxxxx)
       };
#undef F
--------------------------------------------

    Could anyone let me know if this is a correct approach? Thank you.:)

-David

Xiaoliang (David) Wei             Graduate Student in CS@Caltech
http://www.cs.caltech.edu/~weixl
==================================================== 



_______________________________________________
Discussion mailing list
Discussion@xxxxxxxxxx
http://internal.web100.org/mailman/listinfo/discussion