We have encountered several kernel panics in our benchmark tests using
Apache bench (ab).

Test environments are:
  RedHat Enterprise Linux 4.0 update 4
  Apache 2.0.52
  mod_jk 1.2.20
  Tomcat 5.5.17

It turned out to be a kernel bug (see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230976),
and we also found that mod_jk file locking problem in jk_shm.c is a main
cause of the kernel panic.

First, Apache mod_jk parent process opens shared memory file 
"jk-runtime-status" and its lock file "jk-runtime-status.lock".
Next, forked child processes inherit the parent data including file
descriptors (fd) of these files. 
The child processes don't re-open these files.
It then results that all mod_jk processes are locking/unlocking the
same file with same fd.

The problem is that flock system call with LOCK_EX (exclusive lock) 
from a process (A) has no effect if another process (B) has already
locked the same file with same fd.  The flock does not block process A
and returns without an error.  This is how flock works.  
And if process (A) calls flock with LOCK_UN (unlock) to the file, 
the file is unlocked even if process (B) is locking the file, which is
a main cause of the kernel panic.

The child process should re-open the lock file and use a new fd for
flock system call, in order to lock a file strictly.

I have verified that the following code fragments which re-opens a lock 
file for child processes has some effect and does not cause a kernel panic.

jk_shm.c:do_shm_open

    if (jk_shmem.hdr) {
        /* Probably a call from vhost */
        if (JK_IS_DEBUG_LEVEL(l))
            jk_log(l, JK_LOG_DEBUG,
                    "Shared memory is already open");
/* start of temporary code */
        if( attached ) {
          if ((rc = do_shm_open_lock(fname, attached, l))) {
              munmap((void *)jk_shmem.hdr, jk_shmem.size);
              close(jk_shmem.fd);
              jk_shmem.hdr = NULL;
              jk_shmem.fd  = -1;
              JK_TRACE_EXIT(l);
              return rc;
          }
        }
/* end of temporary code */
        return 0;
    }

In such situation, we are afraid that the shared memory is not safe
among multi-processes or multi-threads.

Thank you for your help.