All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Kegel <dank@kegel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "David S. Miller" <davem@redhat.com>,
	arjanv@redhat.com, marcelo@conectiva.com.br,
	khttpd-users@alt.org, linux-kernel@vger.kernel.org
Subject: [PATCH] Re: khttpd rotten?
Date: Mon, 06 May 2002 04:28:30 -0700	[thread overview]
Message-ID: <3CD668DE.9D556B99@kegel.com> (raw)
In-Reply-To: <3CD5CE35.3EF2B62E@kegel.com> <20020505.191422.11638807.davem@redhat.com> <3CD5ECEE.E6C0B894@kegel.com> <20020506112259.A25629@infradead.org>

Christoph Hellwig wrote:
> 
> On Sun, May 05, 2002 at 07:39:42PM -0700, Dan Kegel wrote:
> > ... I say pull it from 2.4.19-pre9.  
> > Marcello, put it out of its misery asap, please...
> > it'd time for khttpd to become a standalone patch again.
> 
> Okay, what about the following:
>  - the below patch remove khttpd from 2.4.19-pre, but lets the
>    sysctls in so it can compile out-of-tree
>  - http://verein.lst.de/~hch/khttpd/khttpd-20020506.tar.gz has a tarball
>    with khttpd as of 2.4.19-pre8, a simple makefile to build it and
>    a simple patch to allow loading it when CONFIG_IPV6 != m,
>    Arjan, could you please put it on the official khttpd website if one
>    still exists.
>  - for 2.5 the sysctls can go aswell

That's probably good.  However, I may have been a bit hasty in
my general condemnation of khttpd.  The following patch seems
to solve the nasty problems; perhaps removing khttpd can wait a bit.
(I only tested the patch briefly, but it makes a lot of sense,
and it did improve things here.)
- Dan

diff -aur linux-2.4.19-pre8.orig/net/khttpd/README linux-2.4.19-pre8/net/khttpd/README
--- linux-2.4.19-pre8.orig/net/khttpd/README	Mon May  6 11:37:33 2002
+++ linux-2.4.19-pre8/net/khttpd/README	Mon May  6 12:10:27 2002
@@ -44,6 +44,7 @@
  
    echo 1 > /proc/sys/net/khttpd/stop
    echo 1 > /proc/sys/net/khttpd/unload 
+   sleep 2
    rmmod khttpd
    
 
@@ -123,7 +124,9 @@
    ===============
    In order to change the configuration, you should stop kHTTPd by typing
    echo 1 > /proc/sys/net/khttpd/stop
-   on a command-prompt.
+   sleep 2
+   on a command-prompt.  (The sleep makes it more likely
+   that all kHTTPd threads notice the stop request.)
 
    If you want to unload the module, you should type
    echo 1 > /proc/sys/net/khttpd/unload
diff -aur linux-2.4.19-pre8.orig/net/khttpd/main.c linux-2.4.19-pre8/net/khttpd/main.c
--- linux-2.4.19-pre8.orig/net/khttpd/main.c	Mon May  6 11:37:33 2002
+++ linux-2.4.19-pre8/net/khttpd/main.c	Mon May  6 11:48:47 2002
@@ -226,6 +226,9 @@
 		if ( (signal_pending(current)) || (sysctl_khttpd_unload!=0) )
 		 	break;
 		 	
+		/* must clear 'stop' flag before starting threads!  -dank */
+		sysctl_khttpd_stop = 0;
+
 		/* Then start listening and spawn the daemons */
 		 	
 		if (StartListening(sysctl_khttpd_serverport)==0)
@@ -277,10 +278,20 @@
 		}
 		
 		/* Then wait for deactivation */
-		sysctl_khttpd_stop = 0;
 
 		while ( (sysctl_khttpd_stop==0) && (!signal_pending(current)) && (sysctl_khttpd_unload==0) )
 		{
+
+#if 0
+		/* FIXME This section seems to be here to restart worker 
+		 * threads that have died for any reason, but it has a bug:
+		 * if 'stop' is set briefly while this thread is asleep, and
+		 * a worker thread notices, it terminates and free its buffer,
+		 * and this thread will restart it without reallocating
+		 * its buffer.  This happened *every time* until I moved
+		 * the 'sysctl_khttpd_stop = 0' statement up above the thread
+		 * creation.  dank@kegel.com
+		 */
 			if (atomic_read(&DaemonCount)<ActualThreads)
 			{
 				I=0;
@@ -295,6 +306,8 @@
 					I++;
 				}
 			}
+#endif
+
 			interruptible_sleep_on_timeout(&WQ,HZ);
 			
 			/* reap the daemons */
diff -aur linux-2.4.19-pre8.orig/net/khttpd/waitheaders.c linux-2.4.19-pre8/net/khttpd/waitheaders.c
--- linux-2.4.19-pre8.orig/net/khttpd/waitheaders.c	Mon May  6 11:37:33 2002
+++ linux-2.4.19-pre8/net/khttpd/waitheaders.c	Mon May  6 11:54:23 2002
@@ -134,7 +134,7 @@
 		CurrentRequest = CurrentRequest->Next;
 	}
 
-	LeaveFunction("WaitHeaders");
+	LeaveFunction("WaitForHeaders");
 	return count;
 }
 
@@ -178,6 +178,12 @@
 	
 	EnterFunction("DecodeHeader");
 	
+	if (Buffer[CPUNR] == NULL) {
+		/* see comments in main.c regarding buffer managemnet - dank */
+		printk(KERN_CRIT "khttpd: lost my buffer");
+		BUG();
+	}
+
 	/* First, read the data */
 
 	msg.msg_name     = 0;

  reply	other threads:[~2002-05-06 11:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-06  0:28 khttpd rotten? Dan Kegel
2002-05-06  2:14 ` David S. Miller
2002-05-06  2:39   ` Dan Kegel
2002-05-06 10:23     ` Christoph Hellwig
2002-05-06 11:28       ` Dan Kegel [this message]
2002-05-06 17:23       ` Luigi Genoni
2002-05-09  9:49       ` David S. Miller
2002-05-09 10:09         ` Christoph Hellwig
2002-05-09 13:04           ` Luigi Genoni
2002-05-11  0:13             ` Ken Brownfield
2002-05-06 14:17     ` Tux in main kernel tree? (was khttpd rotten?) Roy Sigurd Karlsbakk
2002-05-06 16:08       ` Andy Carlson
2002-05-06 23:35         ` Anton Blanchard
2002-05-07 14:42         ` Alan Cox
2002-05-07 15:03           ` Andrea Arcangeli
2002-05-07 15:26             ` Alan Cox
2002-05-07 15:38               ` Andrea Arcangeli
2002-05-07 16:02             ` Luigi Genoni
2002-05-06 17:21       ` Dan Kegel
2002-05-06 18:42       ` John Stoffel
2002-05-06 19:07         ` Diego Calleja
2002-05-06 19:18           ` Cort Dougan
2002-05-06 20:47         ` Michael Rothwell
2002-05-09 11:20           ` Appications in kernelspace (was:Tux in main kernel tree?) Anders Peter Fugmann
2002-05-06 21:52         ` Tux in main kernel tree? (was khttpd rotten?) Paul Jakma
2002-05-09 11:28           ` john slee
2002-05-07  3:00         ` J Sloan
2002-05-09 11:40   ` khttpd rotten? john slee
2002-05-09 11:29     ` David S. Miller
2002-05-09 19:30       ` Andrew Morton
2002-05-09 19:35         ` David S. Miller
2002-05-09 19:39           ` Martin Dalecki
2002-05-10 10:20         ` Andi Kleen
2002-05-10 10:49           ` David S. Miller
2002-05-09 20:12     ` Ian Molton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CD668DE.9D556B99@kegel.com \
    --to=dank@kegel.com \
    --cc=arjanv@redhat.com \
    --cc=davem@redhat.com \
    --cc=hch@infradead.org \
    --cc=khttpd-users@alt.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.