Userspace module return value?

[Marek Habersack]

On Tue, Jul 20, 2004 at 03:09:25PM +0200, Ingo Molnar scribbled:
> 
> * Marek Habersack <grendel at caudium.net> wrote:
> 
> > [...] I have found a solution which takes care of the problem, but
> > feels like a hack - I'm returning TUX_RETURN_USERSPACE_REQUEST every
> > time except when closing the connection, when I return the value
> > returned from tux(TUX_ACTION_FINISH_CLOSE_REQ, req). That seems to
> > work so far, but is it the right solution? Could anybody, please, shed
> > some light on the handle_events return value?
> 
> you should return whatever the tux() call returns. Normally tux() would
> give you a value of 0 (TUX_RETURN_USERSPACE_REQUEST), but occasionally
> it could return TUX_RETURN_SIGNAL (when a signal is caught) or
> TUX_RETURN_EXIT (when Tux is being shut down). These are the only values
> that are returned currently.
> 
> To debug this, could you log all tux() return values that are not 0? To
> do this just start up the Tux daemon manually without the 'daemon'
> prefix. The simplest way is to modify /etc/rc.d/init.d/tux and remove
> the 'daemon' word. This means 'service tux start' will 'hang' after
> startup but you'll get all printfs to that console. You can then abort
> the daemon via Ctrl-C and 'service tux stop'.
I am using syslog to debug the module, here's what gets output when I return
only the values received from tux() (this is the whole request for the
default Debian apache index.html - note that the graphics files referenced from
the index.html do not exist in the document root):

Jul 20 15:28:23 localhost pch_mod[1406]: req->objectname == index.html
Jul 20 15:28:23 localhost pch_mod[1406]: Validating session
Jul 20 15:28:23 localhost pch_mod[1406]: session_is_valid
Jul 20 15:28:23 localhost pch_mod[1406]: Static request, getting the object (index.html)
Jul 20 15:28:23 localhost pch_mod[1406]: Sending the object (index.html)
Jul 20 15:28:23 localhost pch_mod[1406]: normal: closing the connection
Jul 20 15:28:23 localhost pch_mod[1406]: req->objectname == icons/jhe061.png
Jul 20 15:28:23 localhost pch_mod[1406]: Validating session
Jul 20 15:28:23 localhost pch_mod[1406]: session_is_valid
Jul 20 15:28:23 localhost pch_mod[1406]: Static request, getting the object (icons/jhe061.png)
Jul 20 15:28:23 localhost pch_mod[1406]: content_type: req->objectname == icons/jhe061.png
Jul 20 15:28:23 localhost pch_mod[1406]: ext == png
Jul 20 15:28:23 localhost pch_mod[1406]: abort: closing the connection
Jul 20 15:28:23 localhost pch_mod[1406]: req->objectname == icons/apache_pb.png
Jul 20 15:28:23 localhost pch_mod[1406]: Validating session
Jul 20 15:28:23 localhost pch_mod[1406]: session_is_validicons/debian/openlogo-25.jpg
Jul 20 15:28:23 localhost pch_mod[1406]: Validating session
Jul 20 15:28:23 localhost pch_mod[1406]: session_is_valid
Jul 20 15:28:23 localhost pch_mod[1406]: Static request, getting the object (icons/debian/openlogo-25.jpg)
Jul 20 15:28:23 localhost pch_mod[1406]: content_type: req->objectname == icons/apache_pb.png
Jul 20 15:28:23 localhost pch_mod[1406]: ext == png
Jul 20 15:28:23 localhost pch_mod[1406]: abort: closing the connection
Jul 20 15:28:23 localhost pch_mod[1406]: Sending the object (icons/debian/openlogo-25.jpg)
Jul 20 15:28:23 localhost pch_mod[1406]: tux() returned -1
Jul 20 17:28:23 localhost kernel: Possibly unexpected TUX-thread exit(0) at c0117da3?
Jul 20 17:28:23 localhost kernel: TUX: thread 0 stopping ...
Jul 20 17:28:23 localhost kernel: TUX: thread 0 stopped.

Everything works fine until I do several quick Shift-Reloads from the
browser. You can see above that the requests are then overlapped - the
apache_pb.png and openlogo-25.jpg requests are interlaced. The latter file
should never cause the 'Sending the object (icons/debian/openlogo-25.jpg)'
message to appear, since tux returns an error for it. Here's the code that
handles the situation:

if (rval == REQ_STATIC) {
    req->event = 1;
    do_syslog("Static request, getting the object (%s)", req->objectname);
    rval = tux(TUX_ACTION_GET_OBJECT, req);
    if (rval < 0 || req->error) {
      req->event = 2;
      if (content_type(req) == CONTENT_NOTIFY) 
        return send_failure(req, LOG_ERR_OBJECT_NOT_FOUND);
      
      goto abort;
    }
    return rval;
  }

abort:
  do_syslog("abort: closing the connection");
  return tux(TUX_ACTION_FINISH_CLOSE_REQ, req);

So, what seems to be happening is that there is a race condition somewhere
so that the req->priv data gets munged and the module code gets confused. Am
I supposed to do locking anywhere? Note that the above does not happen with
using my "hack" described in the previous mail. The test server is running
inside vmware, one thread, the 2.4.26-ow1 kernel with tux patch 2.4.23-A3
rediffed for the kernel and 3.2.16 tux userland.

regards

marek

p.s. send_failure is not called in the case of .jpg or .png, it is called
for html/html/xhtml/xhtm and uses TUX_ACTION_SEND_BUFFER to send the
message returning the value received from tux().

-------------- 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/20040720/dded036e/attachment.sig>