userspace modules configuration problem and an oops

[Marek Habersack]

Hello list,

  We've got a problem making userspace modules work to handle a single
extension instead of handling all the requests. Here's the setup:

/etc/tux.mime.types:
TUX/module                      htm

module name: qreplace.htm.so, loaded:
opening shared library /usr/lib/tux/modules/qreplace.htm.so
handle: 0x804efb0
TUXAPI_init: 0xb7dea029
TUXAPI_handle_events: 0xb7dea06d
register {qreplace.htm} - TUX returned 0...

tux configured to handle virtual hosts

Module gets initialized but never gets called for requests referencing .htm
files. If I read the Chapter 5 of the tux docs correctly, the above setup 
should result in the qreplace.htm module being called to handle, e.g., 
test.htm request. What happens instead is that on the _first_ request to any 
.htm file, tux keeps the browser busy and the connection open. Once the connection 
is forcibly closed on the client side and the next request is made, tux serves the
referenced file without passing it to the userspace module and with the
text/plain type (a curious thing here: if I turn virtual hosts off, tux will
serve the same file with the text/html mime type instead of text/plain).

The above happens with tux A3 for 2.4 and tux A6 for 2.6.

Running tux userland without -d doesn't reveal any problems, syslog has no
messages from the kernel tux code either.

While testing the above, I've also came across another problem, this time an
oops (tux A6):

Nov 15 21:50:14 colo6 kernel: kernel BUG at fs/namei.c:481!
Nov 15 21:50:14 colo6 kernel: invalid operand: 0000 [#1]
Nov 15 21:50:14 colo6 kernel: Modules linked in:
Nov 15 21:50:14 colo6 kernel: CPU:    0
Nov 15 21:50:14 colo6 kernel: EIP:    0060:[link_path_walk+2269/2944]    Not tainted VLI
Nov 15 21:50:14 colo6 kernel: EFLAGS: 00010216   (2.6.9) 
Nov 15 21:50:14 colo6 kernel: EIP is at link_path_walk+0x8dd/0xb80
Nov 15 21:50:14 colo6 kernel: eax: dde20560   ebx: dd669e68   ecx: dc4d5410 edx: dc4d5470
Nov 15 21:50:14 colo6 kernel: esi: 00000000   edi: dd668000   ebp: dd669eac esp: dd669e30
Nov 15 21:50:14 colo6 kernel: ds: 007b   es: 007b   ss: 0068
Nov 15 21:50:14 colo6 kernel: Process async IO 0/1 (pid: 715, threadinfo=dd668000 task=dde20560)
Nov 15 21:50:14 colo6 kernel: Stack: dd669e68 dd669e6c dd669e68 00000000 dc4d5410 00000000 00000000 ffffffd8 
Nov 15 21:50:14 colo6 kernel:        00000000 00000000 00000000 00000000 00000001 00000000 dfe81080 dc4d5410 
Nov 15 21:50:14 colo6 kernel:        ed5c7610 00000009 df53f9b0 dfd107e0 dd669eac 00000001 00000001 00000000 
Nov 15 21:50:14 colo6 kernel: Call Trace:
Nov 15 21:50:14 colo6 kernel:  [__tux_lookup+16/48] __tux_lookup+0x10/0x30
Nov 15 21:50:14 colo6 kernel:  [tux_lookup+179/272] tux_lookup+0xb3/0x110
Nov 15 21:50:14 colo6 kernel:  [lookup_url+112/1520] lookup_url+0x70/0x5f0
Nov 15 21:50:14 colo6 kernel:  [schedule+670/1168] schedule+0x29e/0x490
Nov 15 21:50:14 colo6 kernel:  [http_process_message+108/800] http_process_message+0x6c/0x320
Nov 15 21:50:14 colo6 kernel:  [tux_schedule_atom+29/48] tux_schedule_atom+0x1d/0x30
Nov 15 21:50:14 colo6 kernel:  [cachemiss_thread+424/464] cachemiss_thread+0x1a8/0x1d0
Nov 15 21:50:14 colo6 kernel:  [default_wake_function+0/32] default_wake_function+0x0/0x20
Nov 15 21:50:14 colo6 kernel:  [ret_from_fork+6/20] ret_from_fork+0x6/0x14
Nov 15 21:50:14 colo6 kernel:  [default_wake_function+0/32] default_wake_function+0x0/0x20
Nov 15 21:50:14 colo6 kernel:  [cachemiss_thread+0/464] cachemiss_thread+0x0/0x1d0
Nov 15 21:50:14 colo6 kernel:  [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18
Nov 15 21:50:14 colo6 kernel: Code: 1a 01 22 c1 34 c0 eb ec 0f 0b 1a 01 22 c1 34 c0 eb 98 89 2c 24 e8 74 f2 ff ff 8 9 f0 e9 4c fe ff ff e8 d8 b8 1e 00 e9 a7 fd ff ff <0f> 0b e1 01 ec ec 34 c0 e9 8f fd ff ff 89 2c 24 e8 4e f2 ff ff 

It happens whenever a request is made that resolves to a symlink on the
filesystem (XFS in our case). After the oops tux cannot be stopped and the
machine must be rebooted.

Any clues as to what might be wrong with either the module setup and the
above oops? Thanks in advance,

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/20041116/cddf95ee/attachment.sig>