Kernel Traffic #167 For 19 May 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1349 posts in 6458K.

There were 416 different contributors. 185 posted more than once. 145 posted last week too.

The top posters of the week were:

1. khttpd Leaving The Kernel; Tux Possibly Going In

5 May 2002 - 10 May 2002 (35 posts) Archive Link: "khttpd newbie problem"

Topics: Web Servers

People: Anton BlanchardDan KegelKen BrownfieldDavid S. MillerAlan CoxAndrea Arcangeli

Dan Kegel reported that khttpd gave an oops on his Power PC, and wouldn't serve any pages when he tried it on his x86. Anton Blanchard asked, "Any reason for not using tux? Its been tested heavily on ppc64, the same patches should work on ppc32." Dan replied, "That's an excellent suggestion. It certainly seems that khttpd is no longer production quality (if it ever was), and tux is." But Ken Brownfield said, "khttpd is very much production quality on IA32, and has been since 2.4.0-test1. TUX2 is not, however, since under load it enters a 99% CPU busy loop. You may not have enough load to cause TUX2 to do this, and TUX1 may not have this problem." But Anton said, "Tux2 has been stable for me on very large specweb runs. Ingo has been able to fix all the bugs I couldnt - a detailed bug report here would be helpful." And Dan pointed out that khttpd had given him oopsen if he tried cycling it up and down in a loop.

Elsewhere, under the Subject: khttpd rotten? (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0205.0/0946.html) Dan said, "Seems like it's time to either fix khttpd or pull it from the kernel. What was the last kernel version where khttpd was stable (if any)?" David S. Miller replied:

We are going to pull it from the kernel.

The only argument is whether to replace it with TUX or not. There is a lot of compelling evidence that suggests that reasonably close performance can be obtained in userspace.

I guess the decision on TUX is not a prerequisite for pulling khttpd though.

Dan replied, "Right. If khttpd had been pulled from 2.4.17, I would have had weeks of warning that khttpd is unstable; instead, I learned only when someone started doing his own stress testing, and I have little time to fix it. 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."

Various patches began floating around; and various folks objected that they'd been using khttpd for awhile with no problems, and were sorry to see it go.

The question of whether Tux would go into the kernel was left open, although it was pointed out that Red Hat already includes it in their kernel. Andrea Arcangeli asked why there was any problem putting it into the main sources if Red Hat already did that, and Alan Cox explained, "The Red Hat goal is to provide an extremely high quality tested distribution. There are several things TuX needs that are stable, and high quality but which Linus rejected because they put TuX specific code in places like the dcache where from a pure clean kernel point of view it is undesirable."

2. More Than 3G RAM Per Process

7 May 2002 - 10 May 2002 (20 posts) Archive Link: "x86 question: Can a process have > 3GB memory?"

Topics: Big Memory Support

People: Robert LoveLuigi Genoni

Clifford White asked if a single process could have over 3G of RAM. Luigi Genoni said that 3.6G was the maximum. Robert Love also said, "You can go to 3.5GB, anything more and stuff starts getting real tight and not very nice. You can only do 3.5/0.5 on non-PAE, though - PAE requires segments to be aligned on 1GB-boundaries."

3. Status Of CML2 (Abandoned)

9 May 2002 (18 posts) Archive Link: "PATCH & call for help: Marking ISA only drivers"

Topics: Kernel Build System

People: Tomas SzepeDave JonesSean HunterAndrew RodlandEric S. Raymond

In the course of discussion, Tomas Szepe asked whatever became of CML2. He said, "I haven't seen any updates since about February and haven't almost certainly stumbled upon a post from ESR for quite long either." Dave Jones replied, "The majority seemed to be of the opinion it was too overfeatured whilst lacking some of the more basic functionality desired from those who would end up using it on a daily basis in favour of eye candy for users who compile a kernel once per release." Someone else remarked, also in reply to Tomas, that Eric S. Raymond had been "blasted" away from the mailing list; which the poster thought unfair, considering how much Eric had put in to the project. Sean Hunter replied:

Perhaps that will be a lesson to the self-styled "Hacker of social systems" that there is a reason he has two ears and only one mouth.

As a low-evel hacker he needed to elicit support from others to get his work recognised and included. He was unwilling to listen to advice and criticism from those who know a lot better than him, and his work was not of such obvious brilliance that people were prepared to accept it without change.

He was not prepared to make the changes folks wanted, so he took his ball and went away in a strop.

But Andrew Rodland agreed with the earlier unnamed poster. He said, "I did a lot of testing and some grunt-level coding on CML2, and I think it addressed a lot of problems that existed, and was getting steadily better. Sure, it had some flaky spots, but I really don't see all of the problems that people had with it. Even autoconfig had this tendency to do the Right Thing. I think it was just about ready to start getting some wide testing and use, when everyone abandoned it... And now nobody wants to use it, because of course patches don't play nice with it, and etc... Pretty sad."

4. BitKeeper Problem

10 May 2002 (4 posts) Archive Link: "BK problem"

Topics: Version Control

People: Larry McVoyEli Carter

Filesystems

Larry McVoy reported, "we've got a problem in one of Linus' trees and it has started to propagate around. I need your help to track it down and fix it. Please run the following script on your Linux BK trees and contact me if it tells you to do so." Eli Carter asked what the problem was, and Larry replied:

The short summary is that two people used Linus' import tools and because of no error on his part, simply the way things worked out, that caused what we call "duplicate keys" (a lot like duplicate inodes, a lot like it) when the trees with the imported patch came together. I wrote a script to fix up the trees after the fact and the application of that script went wrong in Linus' tree but was not noticed until later. It started showing up as pull errors and then we tracked it down.

The long explanation would take me too long to do in email, I have carpal problems and it would amount to writing a "how BK works" paper and that's too much for me right now. If you want to understand the nitty gritty, we can go to voice and I'll tell you. So far, talking doesn't seem to hurt my wrists :)

5. Devfs Bug Hunt

10 May 2002 - 12 May 2002 (5 posts) Archive Link: "[PATCH] devfs v212 available"

Topics: Debugging, FS: devfs

People: Richard GoochAlexander Viro

Richard Gooch announced:

Version 212 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here.

Patch directly available from:

ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz (ftp://ftp.us.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz)

AND:

ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz

NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later.

This is against 2.5.14. Highlights of this release:

- Added BKL to <devfs_open> because drivers still need it

Alexander Viro noticed a race condition, and Richard confirmed it after some investigation. He said:

OK, I've had a look. There is indeed a race there. While it is safe against module unloading, it isn't safe against removal of entries from the directory. I'm considering some different options to fix this (one is simple and obvious, the other will be a little more efficient).

Question: can invalidate_device() and the bdops methods check_media_change() and revalidate() be called with a lock held?

Alexander replied:

Erm... Depends on the nature of lock. Spinlocks are out of question, obviously (at the very least we reread partition table if disk had been changed and you can't make that nonblocking ;-). Semaphore might work, but I would be very careful with deadlocks - the same rereading partition table could add or remove devfs entries.

Could you describe what are you trying to achieve in the callers of check_disc_changed()? I'd been unable to deduce that from code and some comments would be very welcome.

Richard explained:

There are two cases where we want to do a partition re-read:

The point of this is to make sure that the partition list is updated (if media has changed) whenever user-space might care. Without the above code, if the media changes, and thus the partitioning changes, the list of partitions that devfs has is stale. Two things (at least) could go wrong in this case:

The code prevents these problems.

End of thread.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.