From: "Xiaoliang (David) Wei" <weixl@caltech.edu>
To: <discussion@web100.org>
Subject: a bug of web100 patch (for Linux 2.6.13) for non-i386 architecture?
Date: Wednesday, October 19, 2005 1:44 AM

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@caltech.edu)
        };
#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://davidwei.org
====================================================