tux-induced kernel BUG() with userspace modules

[Marek Habersack]

Hello,

  Working on a userspace module, I came across a problem with
TUX_ACTION_REDIRECT_REQ. Unless I am doing something wrong, the following
module is the simplest possible test case to reproduce the bug:

#include <tux.h>

#ifdef TUXAPI_declare
TUXAPI_declare;
#endif

int TUXAPI_handle_events(user_req_t *req)
{
  return tux(TUX_ACTION_REDIRECT_REQ, req);
}

The environment is:

1. tux: tux3 A3 rediffed for 2.4.26 and another for 2.4.26+openwall2,
   compiled with debugging stuff, no cgi, extended logging
2. kernel: as above, 2.4.26 vanilla, 2.4.26-ow2
3. machine: P4/1GB RAM, Athlon/1GB RAM, vmware with 256MB ram - I don't
   think it matters
4. tux sysctls used:
   net/tux/virtual_server = 0
   net/tux/clientport = 81
   net/tux/referer_logging = 1
   net/tux/referer_blocking = 1
   net/tux/logging = 1
   net/tux/max_keepalives = 1000
   net/tux/keepalive_timeout = 30
   net/tux/TDprintk = 0
   net/tux/Dprintk = 1
   net/tux/generate_cache_control = 1
   net/tux/generate_etags = 1
   net/tux/generate_last_mod = 0
   net/tux/defer_accept = 0
   net/tux/all_userspace = 1
   net/tux/http_subdocroot = docroot

The oops itself is:

Aug 18 18:50:59 localhost kernel: kernel BUG at inode.c:1204!
Aug 18 18:50:59 localhost kernel: invalid operand: 0000
Aug 18 18:50:59 localhost kernel: CPU:    0
Aug 18 18:50:59 localhost kernel: EIP:    0010:[iput+578/592]    Not tainted
Aug 18 18:50:59 localhost kernel: EFLAGS: 00010246
Aug 18 18:50:59 localhost kernel: eax: c02cf3ec   ebx: c5de7480   ecx: 00000000   edx: c5de7490
Aug 18 18:50:59 localhost kernel: esi: c7e87000   edi: 00000000   ebp: c65e2ec0   esp: c5df3e3c
Aug 18 18:50:59 localhost kernel: ds: 0018   es: 0018   ss: 0018
Aug 18 18:50:59 localhost kernel: Process tux (pid: 517, stackpage=c5df3000)
Aug 18 18:50:59 localhost kernel: Stack: c5de7480 c5de75a0 c11641c0 c65e2ec0 c5de7480 c5de7480 c01474a0 c5de7480 
Aug 18 18:50:59 localhost kernel:        c63ae6c0 c63ae6c0 c11641c0 c01356b6 c65e2ec0 c63ae6c0 c63ae6c0 c6a4ee40 
Aug 18 18:50:59 localhost kernel:        00000000 00000000 c0133dcd c63ae6c0 c6a4ee40 c63ae6c0 00000000 00000000 
Aug 18 18:50:59 localhost kernel: Call Trace:    [dput+160/368] [fput+198/288] [filp_close+77/128] [sys_close+78/96] [<c883f588>]
Aug 18 18:50:59 localhost kernel:   [<c886e7a0>] [<c883df26>] [<c886e7a0>] [<c883a459>] [<c883bea0>] [wake_up_process+22/32]
Aug 18 18:50:59 localhost kernel:   [<c886e8e4>] [<c886e7a0>] [<c886e8e4>] [<c885671f>] [<c886e7a0>] [<c886e7a0>]
Aug 18 18:50:59 localhost kernel:   [<c886e7a0>] [<c8859aba>] [<c886e7a0>] [<c883de50>] [in_group_p+35/48] [path_release+21/64]
Aug 18 18:50:59 localhost kernel:   [sys_chdir+160/208] [sys_tux+126/128] [system_call+51/56]
Aug 18 18:50:59 localhost kernel: 
Aug 18 18:50:59 localhost kernel: Code: 0f 0b b4 04 66 da 27 c0 e9 e1 fd ff ff 90 8b 54 24 04 8b 42 
Aug 18 18:50:59 localhost kernel:  Possibly unexpected TUX-thread exit(11) at c0107803?
Aug 18 18:50:59 localhost kernel: TUX: thread 0 stopping ...
Aug 18 18:50:59 localhost kernel: PRINT req c6960800 <c883c09e>, sock 00000000
Aug 18 18:50:59 localhost kernel: ... idx: 0
Aug 18 18:50:59 localhost kernel: ... meth:{<null>}, uri:{<null>}, query:{<null>}, ver:{<null>}
Aug 18 18:50:59 localhost kernel: ... post_data:{<NULL>}(0).
Aug 18 18:50:59 localhost kernel: ... headers: {<NULL>}
Aug 18 18:50:59 localhost kernel: PRINT req c6960800 <c883c09e>, sock 00000000
Aug 18 18:50:59 localhost kernel: ... idx: 0
Aug 18 18:50:59 localhost kernel: ... meth:{<null>}, uri:{<null>}, query:{<null>}, ver:{<null>}
Aug 18 18:50:59 localhost kernel: ... post_data:{<NULL>}(0).
Aug 18 18:50:59 localhost kernel: ... headers: {<NULL>}

The PRINT req message repeats infinitely, the machine needs to be rebooted
in order to be able to do anything with tux.
The interesting thing is that the redirect does take place, the backend
server does deliver content and only after that the above happens. I ran tux
userland under gdb since I suspected a segfault in the module somewhere (in
the original on), but no segfault happened and the test module confirmed
that it must have been something else.

The line in inode.c says:

if (inode->i_state == I_CLEAR)
      BUG();

but I'm not sure what inode does tux trying to put - at first I thought that
it might have been a problem with the socket being killed prematurely but
the above oops trace suggests it has something to do with the filesystem on
disk (or /proc, perhaps?), I think. Any help will be appreciated, if more
info/testing is needed - please let me know

TIA,

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/tux-list/attachments/20040818/d6c3201c/attachment.sig>