tux-induced kernel BUG() with userspace modules

Mon Sep 13 14:36:53 UTC 2004

On Wed, Aug 18, 2004 at 05:16:57PM +0200, Marek Habersack scribbled:
Hello again,

  I'm sorry for being a PITA, but could anybody give me a helping hand with
the bug shown below? I will be happy to work on fixing it if I'm given a
little bit of guidance as right now I'm completely in the dark about why it
is happening,

TIA,

marek

> 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

> _______________________________________________
> tux-list mailing list
> tux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/tux-list

-------------- 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/20040913/4efd48c9/attachment.sig>