Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #185 For 22 Sep 2002

By Zack Brown

Table Of Contents


This issue of Kernel Traffic is dedicated to Mildred Brown, Sept 23, 1908 - March 5, 2002. Happy birthday!

Mailing List Stats For This Week

We looked at 1824 posts in 8532K.

There were 432 different contributors. 239 posted more than once. 180 posted last week too.

The top posters of the week were:

1. Chasing OOPSen

4 Sep 2002 - 13 Sep 2002 (21 posts) Subject: "writing OOPS/panic info to nvram?"

Topics: Debugging, Disks: IDE, Disks: SCSI, FS, Networking

People: Alan CoxSuparna BhattacharyaLars Marowsky-BreePavel MachekPaul MackerrasRusty RussellDavid S. MillerJ.A. MagallonMorten HelgesenRoy Sigurd Karlsbakk

Every once in awhile folks talk about better ways of doing oops handling. Are there ways to store the oops on retreivable media, what kind of recovery is possible, etc.; this week, Roy Sigurd Karlsbakk started it off when he read about Apple's OS X.2 writing panic dumps to nvram. He asked if this would be feasible under Linux. Morten Helgesen had also read the same article and thought it wouldn't be too much work, but Alan Cox said, "Its been done years ago. However on a PC you basically have no free nvram so its not terribly useful there." A few posts later, Remco Post remarked that Linux supported plenty of platforms that could use nvram for crash dumps. He also remarked that dumping to a file or to swap was also a possibility.

J.A. Magallon suggested just letting the user specify a partition to receive the dump; but Alan asked, "With what will you write it - not the linux block layer thats for sure. Ingo has patches for doing network dumps which are kind of neat." Suparna Bhattacharya replied:

LKCD for 2.5 (WIP) has a dump driver interface through which different target types can be plugged in. For example Ingo's polled network dump code been integrated as one such dump driver target (generic type), block layer based i/o is available as another target (for those who chose to use it for their raw partition).Down the line specific dump drivers suited for the hardware concerned, e.g Rusty's polled IDE driver, could be plugged in as dump target too, as could NECs work on converting dump block i/o to polled mode.

Conceivably, one may perhaps have alternate targets available on the same system and failover to the suitable one based on the situation. (If the network interface code is the one in trouble, try to dump to the dedicated raw disk or vice versa).

And then, a little later there could be the option of memory save option abstracted as another driver target, to be followed by a soft-reboot (w/o clearing memory) for performing actual dump i/o to persistent storage on architectures where this option works out.

Elsewhere, J.A. said he hadn't realized there was no way to write raw blocks at a low level, and Lars Marowsky-Bree explained:

Not reliably; you _know_ your infrastructure has crashed, otherwise you wouldn't be inside the crash dump handler ;), so you can't possibly trust the normal block layer to write the crash dump (and not write it over your salary and customer database).

Parts of this could probably be circumvented by a checksum of the code which is computed at boot time and checked before the crashdump takes place, but this doesn't deal with a crashed SCSI driver.

A network dump is much safer, though I would suggest running it over a dedicated card / driver combo and on a special ethernet protocol, because you might have lost your IP configuration...

Pavel Machek said that it would be enough for a network dump to work in 99% of cases; but he added, "Floppy seems like safe choice. Verify its special "crash floppy" by checking signature, then write."

Elsewhere, Paul Mackerras also replied to Alan's rhetorical question about being unable to use the block layer to write the oops to disk; Paul said:

Rusty has written a very basic polled-mode IDE driver for precisely this situation. He even tested it on x86 and powermac. :) He has a little user-space program that allocates a file and uses FIOBMAP to work out which disk blocks it is using. The program writes a signature to the blocks and then tells the kernel crashdump module the block numbers. When the kernel panics, it calls the crashdump module which first reads the blocks it was told and makes sure they have the right signature, then writes the oops information to those blocks and then reboots.

IDE was relatively straightforward since you can do basic block I/O with just the ATA-1 or ATA-2 registers and command set and PIO. In contrast, I believe SCSI defeated him. :)

David S. Miller and Alan started trying to explain how the code could be made to work with SCSI as well, but Rusty pointed out problems with their solutions. He also said:

Note that my mini oops dumper object file is a leafnode which doesn't use any external code in the dump path (checked at build time). It is armed with the symbols and device & block offsets by userspace. I plan to update it in the next month, but it's trivial enough (a new driver with one hook in the oops code) to be done after the freeze if reqd.

The interesting bit becomes harvesting those reports: this is a higher level problem (userspace and privacy being the higher levels, respectively).

2. Linux 2.5.34 Released

9 Sep 2002 - 12 Sep 2002 (7 posts) Subject: "Linux 2.5.34"

Topics: FS: JFS, FS: ReiserFS, PCI, SMP

People: Linus Torvalds

Linus Torvalds announced 2.5.34 and said:

Ok, this has a surprising number of fundamental fixes, with some seriously broken details fixed. The "per-cpu" macros didn't do the right thing at ALL, causing silent trouble for softirq's on SMP, for example.

The floppy bio fixes (and yes, the floppy driver really works now) were rather fundamental and embarrassing too. And edge-triggered PCI interrupts really did some rather bad things under the right circumstances.

Other than those fixes (usually one-liners), this includes merges with Al and Andrew, sparc fixes, JFS and ReiserFS updates etc.

Oh, and more pthreads help from Ingo, along with an indecent number of warring fixes for ptrace breakage..

3. Status Of XFS In 2.5

9 Sep 2002 - 13 Sep 2002 (70 posts) Subject: "XFS?"

Topics: FS: XFS

People: Rik van RielGerhard MackAndi KleenAlan CoxShawn LeasChristoph HellwigRobert LoveLinus Torvalds

Someone asked about the status of XFS in 2.5; he or she had seen patches sent to linux-kernel, but hadn't seen any replies from Linus Torvalds on it. The poster asked what needed to be done in order to get XFS into the main tree. Someone replied, saying they thought it was very rude of Linus to just drop the XFS patches. Rik van Riel replied:

If you think you can do things better you should fork Wadix ;)

Linus might not be the easiest user interface and I've had some problems too in the past, but everybody will have to admit that the current system just works in the long run.

A couple posts later, Gerhard Mack added:

Keep in mind Linus gets flooded by patches on a constant basis and also needs to focus on getting core functions working again so I wouldn't be supprised if he hasn't had time to deal with XFS yet.

Hes also known for just deleting his mail que when it gets overloaded so he may not have even read the messages in question.

Someone else pointed out that XFS did not yet work the way it should, and required changes that were still too invasive for Linus' taste. Andi Kleen accused the poster of spreading FUD. He said, "While not being perfect XFS just works fine for lots of people in production and performs very well for a lot of tasks."

A lot of folks said that XFS worked fine for them and was included in many distributions, and Alan Cox said, "The problem has always been that XFS was very invasive code so it might break stuff for people who dont choose to use experimental xfs stuff. Thats slowly improving."

Shawn Leas suggested that one of Linus' lieutenants should sponsor XFS and make sure it got into the kernel. Robert Love said that Christoph Hellwig was working on the XFS merge.

4. ReiserFS Enhancements For 2.4 And 2.5

10 Sep 2002 - 12 Sep 2002 (13 posts) Subject: "[BK] ReiserFS changesets for 2.4 (performs writes more than 4k at a time)"

Topics: FS: ReiserFS, Version Control

People: Hans ReiserOleg DrokinMarcelo TosattiDiego CallejaDave Jones

Hans Reiser posted a ReiserFS patch for kernel 2.4 and said:

This patch should only go in if 2.4.20 is 3 weeks or more away, otherwise it should wait for the next pre1.

It passes all of our testing, but it is the kind of code that is more likely than most to have elusive lurking bugs. It cannot be tested in 2.5 first because 2.5 is too broken at this particular moment. For the lkml readers let me say that it also should not go onto any distros without three weeks of testing.;-)

It substantially reduces CPU consumption for large writes. It does so by finally ridding the code of that 4k at a time write loop that performed a balancing operation and a block allocation for each 4k written. This might be the last substantial patch from Namesys before V4.:) Chris still has some patches that are substantive though which I hope he sends in very soon...

It also contains some trivial fixes in the second of the attachments from Oleg.

Adding back mistakenly forgotten "attrs" mount option, fix a problem with displacing_large_files allocator option and fix a bug in remounting code on remount from readwarite to readwrite mode that can cause livelock if there was delayed unlinks scheduled on the filesystem.

Marcelo, since you know how long it will be until 2.4.20, you should decide if it will go in.

Dave Jones asked what in particular prevented testing this code in 2.5 before risking inclusion in 2.4; Oleg Drokin replied, "I cannot boot into 2.5.34, that's it. ;)" He added that the code seemed stable enough to him. Hans also said to Dave, "Oleg answered this," and went on, "It is a performance tweak, not a new feature. 2.5 is for things like reiser4. Also, remember that we do perform internal testing, and we also tested this on our mailing list, which makes our tweaks much more stable than most of the tweaks that go into 2.5 first. It is strange, but Namesys seems to have much more of a release management infrastructure than most code submitters (I think that means merely that we have one;-), since there are two persons that test every patch, and that makes us oddly unusual). However, waiting for 2.4.21pre1 is also quite reasonable since the number of lines of new code is significant, and reiserfs is used on mission critical servers. A lot depends on just how soon 2.4.20 is planned to come out, and only Marcelo knows that."

Elsewhere, Marcelo Tosatti, replying to Hans' original patch, said there was enough ReiserFS stuff going into 2.4.20; and he didn't want to make testing even more difficult. He said he'd add Hans' new patch in the 2.4.21-pre run. Oleg suggested, "Please pick up at least the fixes from bk:// I am removed everything related to reiserfs_file_write from there now, so you can just do a pull."

Marcelo was willing to do this, but accidentally included the entire patch in -pre6; he asked Oleg to produce a patch to back out all the reiserfs_file_write changes, so he could put out a corrected -pre7 as soon as possible. Hans and Oleg both agreed to this, though they really thought it would be OK to just include the whole patch after all.

At this point, Diego Calleja made some tiobench benchmarks between -pre4 and -pre6; he posted his results, and Hans said, "Thanks for benchmarks. It suggests that the new code doesn't scale to lots of threads as well as the old, but performs much better for single threads. Maybe Oleg can comment on why that might be --- I have no idea." He added, "On the whole it looks like a win, but why more threads perform worse in some cases probably is worth trying to understand. Maybe we should have a seminar on exactly what tiobench is doing and how it interacts with this code."

5. Entries For New 2.4 USB Drivers

10 Sep 2002 - 12 Sep 2002 (2 posts) Subject: "[patch] add entries for CONFIG_USB_SERIAL_KEYSPAN_USA19Q{W,I}"

Topics: USB

People: Marcelo TosattiAdrian BunkGreg KH

Adrian Bunk posted a 2.4 patch to add entries for CONFIG_USB_SERIAL_KEYSPAN_USA19QW and CONFIG_USB_SERIAL_KEYSPAN_USA19QI which were introduced in the 2.4.20-pre run. A couple days later, Greg KH accepted the patches and promised to feed them up to Marcelo Tosatti for inclusion in the main tree.

6. DriverFS Standards

10 Sep 2002 - 12 Sep 2002 (10 posts) Subject: "the userspace side of driverfs"

Topics: FS: driverfs, FS: procfs, PCI, USB

People: Nicholas MiellPatrick MochelGreg KHMiquel van SmoorenburgJ.W. Schultz

Nicholas Miell suggested that in addition to the documentation describing the kernel interface to driverFS, it would be a good idea to specify the format of the files it exported. He said, "In order to prevent driverfs from becoming the maze of twisted files, all different that is /proc, these details need to be specified now, before it's too late." Patrick Mochel replied:

I agree. There has been a lot of talk on this topic, but I don't think much has gotten down on paper, though there might be some in the archives...

The main ideal that we're shooting for is to have one ASCII value per file. The ASCII part is mandatory, but there will definitely be exceptions where we will have an array of or multiple values per file. We want to minimize those instances, though. Both for the sake of easy parsing, but also for easy formatting within the drivers.

In Nicholas' original post, he listed some concerns off the top of his head:

Greg KH replied to that last item, "The "Hub/Port..." thing will change, I have a large "struct device_driver" patch for the USB code that is still being worked on before going into the kernel, and this is changed in that patch.. For all other "name" files, it's something that makes sense for the device, and can be parsed by a human. For some USB devices, they provide device and manufacturer strings, so that information is provided. Other devices do not, so we guess the best that we can." To Nicholas' first item, Patrick said:

Yes. One of the pipe dreams I have, which will hopefully become a reality in the future is to document the attributes when they're defined with a docbook-like comment. These can then be extracted and inserted into a database.

We're working on a utility that abstracts the layout of driverfs from the user. This will allow you do things like list all the devices and drivers of a particular bus or class type, as well as display their attributes. With a database of attribute descriptions, you can provide desciptive context along with the value of the attribute.

To the second item, he said:

The flags bit is a good point, and should probably be removed.

Taking a step back, I would like to note that it would be nice to do something at a higher level with the resource structures; i.e. put them in struct device and deal with them in the driver model core. This is ways out, though if it happens, it will likely have repercussions in their driverfs representation..

Nicholas disagreed, saying that the flags were needed in order to distinguish between dma, irq, mmio, and ports. The other flag bits, he said, were interesting as well; but there was no reply here.

To the third point, Patrick said,
'name' is better referred to as 'description'. It's a bus-specified string that describes the device. The bus is allowed to do as it pleases with it.

Getting back to the file format, Miquel van Smoorenburg had no problem with using ASCII, but felt that it would be possible to restrict the files to a single value in all cases. He said:

If you have multiple values per file, why not make it a directory with multiple files in it, each with one value per file.

If you care about speed, perhaps you can provide a ".array" virtual file in such a (or each) directory, that when read returns all files in the directory in "filename: value" format so that you avoid the while (readdir()) { open(); close(); } overhead.

This would be much cleaner, think for example of how you would otherwise _write_ individual entries in such an array.

If you really want to get overboard, provide a sysctl() like function that can read the entries in driverfs in binary. Like the existing sysctl() in linux, but with an added TYPE_INT, TYPE_STRING etc flag for each value for consistency. It too should be able to read an entire directory as an array.

Then, convert procfs to the same interface ;)

Nicholas objected, "But subdirectories are child devices. Having array directories and device directories would complicate the apps that have to parse this data." But there was no reply to that.

J.W. Schultz also commented on this issue elsewhere. He said:

I don't know what others think of this but i'd say that some binary files are appropriate. In a case like this i'd say a files named 'nvram' and 'bios' or 'firmware' would be good candidates for opaque binary structures and firmware. This is particularly the true if the data is purely related to the device. Ultimately it'd be nice to be able to upload and download (install) firmware this way.

Now if a datum is a parameter suitable for tuning i'd like it made visible and updatable in an ASCII form. In other words i'd like to see an end to the proliferation of obscure tools like hdparm.

But Patrick vetoed this utterly. He said, "Not a chance. The values will be ASCII, and that's all there is to it. If I see someone exporting a binary file in driverfs, I'll submit a patch to remove it. :)"

7. New AIM Benchmarking Tool

10 Sep 2002 - 12 Sep 2002 (8 posts) Subject: "Performance differences in recent kernels"

People: Hans ReiserRandy DunlapRandy Hron

Randy Hron posted some benchmarks and gave a link to even more. Hans Reiser was very happy to see these results, because they showed that some performance patches that had not yet made it into the kernel were actually really great. He asked, "AIM is a proprietary benchmark, yes? If we send you a copy of reiser4 next month, would you be willing to give it a run?" Randy Dunlap replied, "No, it's now GPL and available at" Hans replied:

Thanks much to caldera for doing this. I have wanted to try the benchmark for years, but it was too expensive for us.

We'll use it for debugging and benchmarking reiser4 also.

8. Handling Out-Of-Memory Conditions

11 Sep 2002 - 16 Sep 2002 (43 posts) Subject: "Killing/balancing processes when overcommited"

Topics: Forward Port

People: Alan CoxGiuliano PochiniRik van RielJim SibleyRobert Love

Jim Sibley noticed that when his system ran out of memory, seemingly random processes were being killed. Alan Cox replied, "The best case is that you don't allow overcommit. 2.4 supports that in the Red Hat and -ac trees. Robert Love forward ported the changes to 2.5.x. There is an outstanding need to add an additional "root factor" so root can get some memory other people cannot, but otherwise it seems to work well."

Close by, considering a system of automatically killing 'the right' processes when the system runs out of memory, Giuliano Pochini remarked, "It's not difficult to make the kerner choose the right processes to kill. It's impossible." Rik van Riel came back with, "This assumes there is only 1 "good" process to kill. In reality there will often be a number of acceptable candidates, so we just need to identify one of those ;)" At one point in the discussion, Jim said, "I still favor an installation file in /etc specifying the order in which things are to be killed. Any alogrithmic assumptions are bound to fail at some point to the dissatisfaction of the installation." Giuliano agreed with this. Other folks favored Alan's solution of disallowing overcommits. No code was posted, and the discussion eventually petered out inconclusively.

9. Linux 2.4.20-pre5-ac5 Released

11 Sep 2002 - 12 Sep 2002 (4 posts) Subject: "Linux 2.4.20pre5-ac5"

Topics: Disks: IDE, Kernel Release Announcement, PCI

People: Alan Cox

Alan Cox announced 2.4.20-pre5-ac5:

Next stage IDE cleanup. This still has the ide-scsi oops, and simplex breakage. We know why both of those occur I think so they should be fixed next time.

You can now load ide pci drivers at boot time or as modules. Don't try unloading the modules yet.

Linux 2.4.20-pre5-ac5

10. Ebtables Ethernet Bridge Tables For 2.5.34

11 Sep 2002 - 17 Sep 2002 (21 posts) Subject: "[PATCH] ebtables - Ethernet bridge tables, for 2.5.34"

Topics: Networking

People: Bart De SchuymerDavid S. MillerLennert Buytenhek

Bart De Schuymer announced:

Ebtables is a project similar to iptables, but working on the bridge netfilter hooks. It allows for a basic transparent firewall, making a brouter and doing MAC source address and destination address manipulation. The firewall part has currently modules for basic IP filtering, 802.1q filtering, ARP filtering, logging and a mark match/target.

Ebtables has been under development for over 1.5 year and has more than 100 users, I think.

The patch is 3662 lines long, so I won't list it in this mail. It is available at: or, gzipped:

It is vs 2.5.34, I can make a patch vs 2.4.x when the time is right. Comments/questions are appreciated.

For more information, see
There is an ebtables hacking howto, some basic examples and some real life examples from users. And ofcourse the userspace program.

David S. Miller took a dim view of this at first. He said, "People should use ARP tables for arp filtering, that is why I wrote it. ARP filtering should not need to be bridge specific." Bart explained, "Well, a bridge can also just _bridge_ ARP packets between two sides of the bridge. The ARP module can filter out those packets. These packets will not pass through the ARP code of the Linux kernel. Ofcourse, the ebtables ARP module can be easily adjusted for arptables, I will do this later if nobody beats me to it... For the same reason, basic ebtables IP filtering is not redundant." This made sense to David. He said:

No, I think I understand the difference and why you're problem space does not intersect what arptables handles.

It may not be nice that we can't immediately just reuse ipv4/netfilter handlers for bridging, but I'm not going to require that you make that work before I'll accept your patch.

They proceeded to discuss the possible implementation. David also wanted to make sure that Lennert Buytenhek, the bridging maintainer, agreed with everything before David would merge it. So Bart also sent code to Lennert for approval.

11. Managing Files Generated During Kernel Compilation

11 Sep 2002 - 12 Sep 2002 (3 posts) Subject: "[PATCH] Generated files destruction"

Topics: Kernel Build System

People: Rusty RussellKai Germaschewski

Rusty Russell posted a quick patch, and said, "I would like to start migrating all build-generated files to names matching "generated*" or ".generated*", esp. those which look like source files. This is mainly for readability and for simplicity when diffing built kernel trees. I'll be encouraging various maintainers who generate (.c, .h and .s) files which are not meant to be shipped with the kernel source to migrate, in my copious free time..." Kai Germaschewski replied, "I think the proper solution here is actually separate obj/src dirs, instead of special names. It's actually quite easy to get that implemented in the current kbuild, I just didn't find the time for proper testing yet. I'll have a patch ready for testing soon, though." And Rusty replied, "Sure, if it basically comes for free. Otherwise, I don't see any attraction in separating them: cp -al linux-2.5.34 working-2.5.34-foo takes a couple of seconds."

12. Per-CPU Data Available As Early As Possible

11 Sep 2002 (1 post) Subject: "[PATCH] Only allocate per-cpu copies for possible CPUs"

People: Rusty Russell

Rusty Russell posted a patch to allocate per-cpu areas only for those CPUs which may actually exist, before each one would come online. He explained:

Not quite as neat as I would like, but it means that per-cpu vars are still usable on the boot CPU early, and usable on the other cpus by the time they are called online.

The problem is that some people want to use per-cpu vars before we have probed for cpus, so we don't know what CPUs are possible, hence this "alloc the boot cpu using bootmem and the other cpus using kmalloc" approach.

This is a precursor to pushing "change all [NR_CPUS] arrays to per-cpu vars" (which then implies that the per-cpu area pointer, not the cpu number, becomes the primary object from which the other is derived.

13. Threading Fixes In 2.5

12 Sep 2002 - 14 Sep 2002 (3 posts) Subject: "[patch] sys_exit() fix, 2.5.34-D5"

Topics: FS: procfs, SMP, Version Control

People: Ingo MolnarLinus Torvalds

Ingo Molnar posted a patch to Linus Torvalds and explained:

the attached patch fixes some problems introduced by detached threads and the wait-on-group-exit concept.

it was possible for threads to schedule away as zombies and be freed by wait4 - while they still had some work to do.

the main problem was the ability of wait4 to release tasks. The patch removes the release_task() from the wait4 path and makes it a wake_up_process() instead. TASK_ZOMBIE is thus not a condition mandatorily preceding task exit, it's rather a task flag that is used by wait4 to find exiting threads. I've added free_task() that does the real freeing work - it's always called by the thread that exits.

what impact does this solution have?

i think the additional context switch in the non-detached case is acceptable, it's detached threads that care most about exit() performance anyway.

the patch also adds some temporary debugging code that makes sure freed tasks are not woken up by wait4.

i've moved the 'wait for all other threads to exit' logic to before parent notification. Once current->thread_group becomes empty there's no way the thread can get new thread group children - so there are no races to worry about.

i've tested the patch with normal process load, old-style and new-style threading workloads, and some ptrace load.

The next day he followed up with another patch, explaining:

this patch implements the 'keep the initial thread around until every thread in the group exits' concept in a different, less intrusive way, along your suggestions. There is no exit_done completion handling anymore, freeing of the task is still done by wait4(). This has the following side-effect: detached threads/processes can only be started within a thread group, not in a standalone way.

(the patch also fixes the bugs introduced by the ->exit_done code, which made it possible for a zombie task to be reactivated.)

i've introduced the p->group_leader pointer, which can/will be used for other purposes in the future as well - since from now on the thread group leader is always existent. Right now it's used to notify the parent of the thread group leader from the last non-leader thread that exits [if the thread group leader is a zombie already].

The next day he followed up with another patch, explaining, "the attached patch (against BK-curr) fixes the Mozilla SMP lockup in the exit path."

14. User-Mode Linux Going Into 2.5

12 Sep 2002 - 13 Sep 2002 (11 posts) Subject: "UML 2.5.34"

Topics: User-Mode Linux

People: Jeff DikeAndrew Morton

Jeff Dike announced:

UML has been updated to 2.5.34 and UML 2.4.19-3.

There have been only a few minor changes since UML 2.5.33. This is mostly an update to 2.5.34.

The patch is available at

For the other UML mirrors and other downloads, see

Other links of interest:

The UML project home page :
The UML Community site :

Andrew Morton replied, "And Linus has merged it. Congratulations, Jeff." Jeff replied, "Thanks! It's great to finally have it in."

15. Maintainer List

12 Sep 2002 (1 post) Subject: "lk maintainers"

Topics: Bug Tracking, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: NFS, FS: NTFS, FS: ReiserFS, FS: autofs, FS: devfs, FS: ext2, FS: ext3, FS: smbfs, Framebuffer, Hot-Plugging, I2O, Kernel Build System, Networking, PCI, Real-Time: RTLinux, Samba, Serial ATA, Software Suspend, Sound: ALSA, Spam, USB, Virtual Memory

People: Denis VlasenkoTrond MyklebustJan KaraArnaldo Carvalho de MeloAlexander ViroHans ReiserRik van RielLinus TorvaldsVojtech PavlikGeert UytterhoevenJeff GarzikAndre HedrickGreg KHJaroslav KyselaAnton AltaparmakovTigran AivazianMartin J. BlighArjan van de VenEric S. RaymondMike PhillipsOleg DrokinH. Peter AnvinAlan CoxPavel MachekDave JonesRichard GoochAndrew MortonJens AxboeIngo MolnarVictor YodaikenJames SimmonsTim WaughRusty RussellGerd KnorrAndrea ArcangeliMartin DaleckiDavid S. MillerRogier WolffUrban WidmarkPaul LarsonPetr VandrovecMarcelo TosattiNeil BrownRussell KingRalf BaechleKeith OwensRobert LoveMaksim Krasnyanskiy

Denis Vlasenko announced:

So, you are new to Linux kernel hacking and want to submit a kernel bug
report or a patch but don't know how to do it and _where_ to report it?

Preparing bug report:
Compile problems: report GCC output and result of "grep '^CONFIG_' .config"
Oops: decode it with ksymoops
Unkillable process: Alt-SysRq-T and ksymoops relevant part
Yes it means you should have ksymoops installed and tested,
which is easy to get wrong. I've done that too often.

More info in the FAQ at

Sending bug report/patch:
* Some device drivers have active developers, try to contact them first.
* Otherwise find a subsystem maintainer to which your report pertains
  and send report to his address.
* Small fixes and device driver updates are best directed to subsystem
  maintainers and "small bits" integrators.
* It never hurts to CC: Linux kernel mailing list, but without specific
  maintainer address in To: field there is high probability that your
  patch won't be noticed. You have been warned.
* Do not send it to all addresses at once! This will annoy lots of people
  and isn't useful at all. It's a spam.
* Do NOT send small fixes to Linus, he just can't handle _everything_.
  He will eventually receive it from maintainers/integrators, send it
  their way.
* If your patch is something big and new, announce it on lkml and try
  to attract testers. After it has been tested and discussed, you can
  expect Linus to consider inclusion in mainline.

                Current Linux kernel people

Note that this list is sorted in reversed date order, most recent
entries first. This means than entries at bottom can be outdated :-(

Linux kernel mailing list <[email protected]>
        Post anything related to Linux kernel here, but nothing else :-)

Jan Kara <[email protected]> [22 aug 2002]
        quota subsystem maintainer

Paul Larson <[email protected]> [20 aug 2002]
        I'm a maintainer for the Linux Test Project and it would be nice
        if people knew to send their test programs, etc. to me.  I see
        a lot of them flying around on lkml and try to catch them when
        I can, but it's a lot to keep up with.  It would be even better
        if people just knew to send them our way so we could clean
        them up and put them in LTP for regression testing.

Dave Engebretsen <[email protected]> [15 aug 2002]
        PPC64 architecture maintainer.  Please send PPC64 patches to me
        and our mailing list at <[email protected]>

Ingo Molnar <[email protected]> [30 jul 2002]
        Ingo wrote the new scheduler for 2.5.

Ralf Baechle <[email protected]> [30 jul 2002]
        I am maintainer of the AX.25 code

Victor Yodaiken <[email protected]> [30 jul 2002]
        RTLinux patches, updates, contributions, drivers.
        Please send first to the list: [email protected]

Pavel Machek <[email protected]> [27 jul 2002]
        I am network block device maintainer. Visit
        (see Steven Whitehouse <[email protected]> entry)
        I am working on software suspend.

William Irwin <[email protected]> [02 jul 2002]
        Send bug reports and/or feature requests related to many tasks,
        rmap, space consumption, or allocators to me. I'm involved in
        * rmap
        * memory allocators
        * reducing space consumed by data structures (e.g. struct page)
        * issues arising in workloads with many tasks
        * kernel janitoring
        See also:
        Rik van Riel <[email protected]>
        Andrea Arcangeli <[email protected]>
        Martin Bligh <[email protected]>
        Andrew Morton <[email protected]>

Dave Jones <[email protected]> [23 apr 2002]
        I collect various bits and pieces for inclusion in 2.5,
        especially small and trivial ones and driver updates.
        I'll feed them to Linus when (and if) they
        are proved to be worthy.

Andre Hedrick <[email protected]> [09 apr 2002]
        ATA/ATAPI Storage Architect [2.0,2.2,2.4]
        HBA interface developer
        Serial ATA Architect [future release]
        Voting NCITS member AT-Attachment Committee

Andrea Arcangeli <[email protected]> [28 mar 2002]
        Send VM related bug reports and patches to me.
        I'm especially interested in VM issues with:
        * lots of RAM and CPUs
        * NUMA
        * heavy swap scenarios
        * performance of I/O intensive workloads (in particular
          with lots of async buffer flushing involved)
        See also Martin J. Bligh <[email protected]> entry
        Mail also:
        Arjan van de Ven <[email protected]>

Martin J. Bligh <[email protected]> [28 mar 2002]
        I'm interested in VM issues with lots (>4G for i386)
        of RAM, lots of CPUs, NUMA

Steven Whitehouse <[email protected]> [27 mar 2002]
        I am the Linux DECnet network stack maintainer

Arnaldo Carvalho de Melo <[email protected]> [26 mar 2002]
        IPX, 802.2 LLC, NetBEUI,,
        cyclom2x sync card driver

John Cagle <[email protected]> [19 mar 2002]
        The current maintainer of devices.txt, the list of
        assigned device numbers for LANANA.  Consult the web
        site ( for instructions on submitting
        requests for new device numbers.  Send all device
        related email to <[email protected]>.

Tigran Aivazian <[email protected]>
        I am author and maintainer of BFS filesystem and IA32
        microcode update driver.

Rogier Wolff <[email protected]> [12 mar 2002]
        I do "specialix serial ports":
        drivers/char/specialix.c (IO8+)
        drivers/char/sx.c        (SX, SI, SIO)
        drivers/char/rio/*.c     (RIO)

Martin Dalecki <[email protected]> [11 mar 2002]
        IDE subsystem maintainer for 2.5
        (mail Vojtech Pavlik <[email protected]> too)

Ed Vance <[email protected]> [05 mar 2002]
        Maintainer for the generic serial driver, serial.c,
        for 2.2 and 2.4 kernels.  Please post patches to
        [email protected] for tested bug
        fixes or to add support for a new serial device.
        Limited to time available. If I have not responded
        in a week, yell at [email protected]

netfilter/iptables development <[email protected]> [23 feb 2002]
        Please report all netfilter/iptables related problems
        to this mailinglist, where all netfilter developers are present.
        See also

Hans Reiser <[email protected]> [16 feb 2002]
        Send me all reiserfs related patches with a cc to
        [email protected], send bug reports to
        [email protected], send paid support requests to
        [email protected] after going to
        to pay, send discussions (not bug reports unless they are
        interesting to most persons) to [email protected]
        If we sit on your patch for a week without responding,
        yell at us, we deserve it.  Look at our web page
        at for more about sending us code,
        working with us, and our patch submission and tracking system.

Paul Bristow <[email protected]> [16 feb 2002]
        I am an ide-floppy driver maintainer
        (ATAPI ZIP, LS-120/240 Superdisk, Clik! drives).

Mike Phillips <[email protected]> [15 feb 2002]
        Token ring subsystem and drivers.

Anton Altaparmakov <[email protected]> [15 feb 2002]
        I am the NTFS guy. [14 feb 2002]
        Reports of problems with the Red Hat shipped kernels.

Alan Cox <[email protected]> [14 feb 2002]
        Linux 2.2 maintainer (maintenance fixes only).
        Collator of patches for unmaintained things in 2.2/2.4.
        Maintainer of the 2.4-ac (2.4 plus stuff being tested) tree.
        I2O, sound, 3c501 maintainer for 2.2/2.4.

Robert Love <[email protected]> [14 feb 2002]
        Preemptible kernel is mine.

ALSA development <[email protected]> [12 feb 2002]
Jaroslav Kysela <[email protected]> [12 feb 2002]
        Advanced Linux Sound Architecture
        ALSA patches are available at*

Neil Brown <[email protected]> [08 feb 2002]
        I am interested in any issues with the code in:
        NFS server    (fs/nfsd/*)
        software RAID (drivers/md/{md,raid,linear}*)
        or related include files.

Maksim Krasnyanskiy <[email protected]> [08 feb 2002]
        I'm author and maintainer of the Bluetooth subsystem
        and Universal TUN/TAP device driver.
        These days mostly working on Bluetooth stuff.

Rik van Riel <[email protected]> [07 feb 2002]
        Send me VM related stuff, please CC to [email protected]

Geert Uytterhoeven <[email protected]> [07 feb 2002]
        I work on the frame buffer subsystem, the m68k port (Amiga part),
        and the PPC port (CHRP LongTrail part).
        Unfortunately I barely have spare time to really work on these
        things. My job is not Linux-related (so far :-). I can not
        promise anything about my maintainership performance.

H. Peter Anvin <[email protected]> [07 feb 2002]
        i386 boot and feature code, i386 boot protocol, autofs3,
        compressed iso9660 (but I'll accept all iso9660-related
        changes.) site manager; please contact me
        for sponsorship-related issues. admins <[email protected]> [07 feb 2002] sysadmins.  Contact us if you notice something breaks,
        or if you want a change make sure you give us at least 1-2 weeks.
        Please note that we got a lot of feature requests, a lot of
        which conflict or simply aren't practical; we don't have time to
        respond to all requests.

Greg KH <[email protected]> [07 feb 2002]
        I am USB and PCI Hotplug maintainer.

Trond Myklebust <[email protected]> [07 feb 2002]
        I am NFS client maintainer.

James Simmons <[email protected]> [07 feb 2002]
        Console and framebuffer sybsustems.
        I also play around with the input layer.

Richard Gooch <[email protected]> [07 feb 2002]
        I maintain devfs. I want people to Cc: me when reporting devfs
        problems, since I don't read all messages on linux-kernel.
        Send devfs related patches to me directly, rather than
        bypassing me and sending to Linus/Marcelo/Alan/Dave etc.

Russell King <[email protected]> [06 feb 2002]
        ARM architecture maintainer.  Please send all ARM patches through
        the patch system at
        New serial drivers maintainer for 2.5.  Submit patches to
        [email protected]

Andrew Morton <[email protected]> [05 feb 2002]
        I'm receptive to any reproducible bug anywhere in the 2.4 kernel.
        Specialising in ext2, ext3 and network drivers.
        Not thinking about 2.5.x at this time.

Petr Vandrovec <[email protected]> [05 feb 2002]
        ncpfs filesystem, matrox framebuffer driver, problems related
        to VMware - in all of 2.2.x, 2.4.x and 2.5.x.

Reiserfs developers list <[email protected]> [05 feb 2002]
        Send all reiserfs-related stuff here including but not limited to bug
        reports, fixes, suggestions.

Oleg Drokin <[email protected]> [05 feb 2002]
        SA11x0 USB-ethernet and SA11x0 watchdog are mine.

Vojtech Pavlik <[email protected]> [05 feb 2002]
        Feel free to send me bug reports and patches to input device drivers
        (drivers/input/*, drivers/char/joystick/*)
        I also want to receive bug reports and patches for following
        USB drivers: printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
        All other (not in the list) USB driver changes should go to USB
        maintainer (hopefully there is one listed here :-).
        Also CC me if you are posting VIA IDE driver related message
        (although I am not IDE subsystem maintainer).

======= These entries are suggested by lkml folks ========

Ralf Baechle <[email protected]> [27 mar 2002]
        I am mips/mips64 maintainer.

David S. Miller <[email protected]> [07 feb 2002]
        I am Sparc64 and networking core maintainer.

======= These ones I made myself ========
======= I am waiting confirmation/correction from these people ========

Urban Widmark <[email protected]> [13 feb 2002]

Jeff Garzik <[email protected]> [12 feb 2002]
        I am the network-card-drivers guy (8139 for instance).
        CC me and Andrew Morton <[email protected]> on network driver patches.

video4linux list <[email protected]> [12 feb 2002]
Gerd Knorr <[email protected]> [12 feb 2002]

Tim Waugh <[email protected]> [08 feb 2002]
        > Who is maintaining the linux iomega stuff?
        For 2.4.x, me (in theory). I don't have time for 2.5.x at the moment.

Alexander Viro <[email protected]> [5 feb 2002]
        I am NOT a fs subsystem maintainer. But I won't kill
        you if you send me some generic fs bug reports and (hopefully) patches.

Eric S. Raymond <[email protected]> [5 feb 2002]
        Send kernel configuration bug reports and suggestions to me.
        Also I'll be more than happy to accept help enties for kernel config
        options (

G?rard Roudier <[email protected]> [5 feb 2002]
        I am SCSI guy.

Jens Axboe <[email protected]> [5 feb 2002]
        I am block device subsystem maintainer.

Keith Owens <[email protected]> [5 feb 2002]
        ksymoops, kbuild, .. .. .. .. .  are mine.

Linus Torvalds <[email protected]> [5 feb 2002]
        Do not send anything to me unless it is for 2.5, well tested,
        discussed on lkml and is used by significant number of people.
        In general it is a bad idea to send me small fixes and driver
        updates, send them to subsystem maintainers and/or
        "small stuff" integrator (currently Dave Jones <[email protected]>,
        see his entry). Sorry, I can't do everything.

Marcelo Tosatti <[email protected]> [5 feb 2002]
        Do not send anything to me unless it is for 2.4 and well tested.
        If you are sending me small fixes and driver updates, send
        a copy to subsystem maintainers and/or "small stuff" integrators:
        - Alan Cox <[email protected]>,
        - Rusty Russell <[email protected]>.

Rusty Russell <[email protected]> [5 feb 2002]
        > Here are some cleanups of whitespace in .....
        Want me to add this to the trivial patch collection for tracking?
        If so just send (or cc:) it to [email protected]

16. Linux 2.4.20-pre7 Released

12 Sep 2002 - 13 Sep 2002 (8 posts) Subject: "Linux 2.4.20-pre7"

Topics: Extended Attributes, FS: JFS, FS: ReiserFS, PCI, Samba, USB, Version Control

People: Marcelo TosattiGeert UytterhoevenJeff GarzikJean TourrilhesDavid BrownellPaul MackerrasAdrian BunkSteven ColeBjorn HelgaasOliver NeukumDave KleikampIvan KokshayskyMaksim Krasnyanskiy

Marcelo Tosatti announced 2.4.20-pre7, saying:

So here goes -pre7. Big MIPS and IA64 merge.

The on boot crashes with i845 should be fixed now.

Summary of changes from v2.4.20-pre6 to v2.4.20-pre7

<[email protected]>:
  o Sync up syscall table with 2.5

<[email protected]>:
  o fix ramdisk cache flush

<[email protected]>:
  o [PATCH] (repost) fix for big endian machines in scanner.c

<[email protected]>:
  o inline grab_cache_page
  o cleanup try_to_free_pages naming
  o fix syscall prototypes in init/do_mounts.c

<[email protected]>:
  o HandyTech HandyLink patch

<[email protected]>:
  o PPC32: Add extended attributes syscalls

<[email protected]>:
  o 2.4.20-pre6: befs still not in fs/Makefile

<[email protected]>:
  o mips
  o mips64
  o mips64-ip27
  o mips-sgi-ip22
  o mips-ip32
  o mips-mips
  o mips-sibyte
  o maintainers
  o drivers-net-mace
  o drivers-net
  o drivers-net
  o drivers-net
  o drivers-net
  o drivers-net
  o drivers-sgi
  o mips-cobalt
  o pci-ids
  o drivers-scsi
  o drivers-scsi
  o drivers-tc
  o drivers-ide
  o drivers-ide
  o mips-arc
  o mips-dec
  o mips-alchemy
  o mips-galileo-boards
  o drivers-video
  o drivers-video
  o mips-vr41xx
  o mips-momentum
  o mips-ddb
  o drivers-mtd
  o drivers-mtd

<[email protected]>:
  o NVRAM driver

<[email protected]>:
  o trivial ohci fixes

Adrian Bunk <[email protected]>:
  o entry for the ForteMedia FM801 driver
  o add entries for CONFIG_USB_SERIAL_KEYSPAN_USA19Q{W,I}

Bjorn Helgaas <[email protected]>:
  o IA64 sync

Dave Kleikamp <[email protected]>:
  o JFS: add permission checks before getting or setting xattrs

David Brownell <[email protected]>:
  o usbcore updates

Geert Uytterhoeven <[email protected]>:
  o M68k extended attributes
  o Fixup fbcon build

Greg Kroah-Hartman <[email protected]>:
  o USB serial: added device path to the proc file now that usb_make_path() is

Ivan Kokshaysky <[email protected]>:
  o transparent pci-pci bridges fix
  o alpha rwsem update

Jean Tourrilhes <[email protected]>:
  o Fix stupid compile error in wavelan_cs

Jeff Garzik <[email protected]>:
  o Add kernel-related BitKeeper docs/scripts, as found in the 2.5.x kernel
Documentation/BK-usage sub-directory.

Maksim Krasnyanskiy <[email protected]>:
  o 2.4.20-pre6 Bluetooth core fixes

Marcelo Tosatti <[email protected]>:
  o Fix tg3 compile problems
  o Remove reiserfs not very well tested code
  o tg3.c
  o Fix bogus printk which was resulting in bootup oops
  o Add asm-ia64/include/efi.h needed by generic efi code

Oliver Neukum <[email protected]>:
  o new ids for hpusbscsi

Paul Mackerras <[email protected]>:
  o PPC32: Add declaration of gg2_pci_config_base variable
  o don't use outl as label in ppp_generic.c
  o PPC fix in drivers/pci/Makefile
  o kd_mksound inclusion on PPC

Steven Cole <[email protected]>:

17. Configuration Option To Prevent Script Support

12 Sep 2002 (1 post) Subject: "Patch to make shbang scripts a configuration option"

Topics: Small Systems

People: Mark Veltzer

Mark Veltzer announced his first contribution to the kernel:

This patch adds a tri state option in configuration so that kernels could be created without scripts support (shbang first line).

Why would you want that ? Embedded systems which only run a few binaries and would like to save a little RAM. The default is 'Y' and the states that you should put a 'Y' if unsure.

The patch is for 2.4.19.

18. Multiple kswapd Processes On A Single Machine

12 Sep 2002 - 16 Sep 2002 (24 posts) Subject: "[PATCH] per-zone kswapd process"

Topics: Big Memory Support, Virtual Memory

People: William Lee Irwin IIIRik van RielDave HansenAlan CoxAndrew Morton

Dave Hansen announced:

This patch implements a kswapd process for each memory zone. The original code came from Bill Irwin, but the current VM is quite a bit different from the one that he wrote it for, so not much remains. The current kswapd interface is much more simple than before because there is a single waitqueue and there is a single place where it is emptied.

kswapd_can_sleep() and kswapd_balance() are simpler now that the extra pgdat level of indirection is gone.

Tested on 8-way PIII with highmem off and then 4GB support. With 4GB support, I did 20 parallel greps through a 10GB fileset while some other processes allocated and freed 1-2GB chunks of memory. That gave kswapd a good workout, and I observed it running the zone Highmem and zone Normal kswapd threads. So, it survives my torture test. It also removes more code than it adds.

Andrew Morton felt that a per-node implementation would be sufficient, without going to the extreme of implementing it on a per-zone basis, but William Lee Irwin III replied, "Machines without observable NUMA effects can benefit from it if it's per-zone. It also follows that if there's more than one task doing this, page replacement is less likely to block entirely. Last, but not least, when I devised it, "per-zone" was the theme." Andrew was not convinced by this, and said that if there were any benefit to be seen, it would probably also indicate a bug in the VM subsystem. Alan Cox also suspected that William's solution would increase the amount of disk-head thrashing, but William disagreed. He abdicated eventually, saying:

The notion was that some level of parallelism would be bestowed on the single-node case by using separate worker threads on a per-zone basis, as they won't have more than one node to spawn worker threads for at all.

This notion apparently got shot down somewhere, and I don't care to rise to its defense. I've lost enough debates this release to know better than to try.

Rik van Riel offered some comfort, saying, "Don't worry about this, there are bigger fish around, lower hanging sea fruit, so to say. ;)"

19. Release Notes For The -ac Tree

13 Sep 2002 (3 posts) Subject: "-ac patch: Which release notes?"

Topics: Disks: IDE

People: Alan Cox

Someone noticed that the IDE/ATA section of the -ac kernel configuration options asked if the user had read the release notes. The poster asked what release notes these were. Were they the README distributed with each kernel? Alan Cox replied, "The release notes are the ones posted to the kernel list and to the news sites. I guess I should include them in the kernel too 8)."

20. Status Of ACPI

13 Sep 2002 (5 posts) Subject: "ACPI Status"

Topics: Power Management: ACPI

People: Andrew GroverMatthew Wilcox

Marc Giger asked about the status of ACPI in 2.4 and 2.5 kernels. He complained that seemed outdated; and asked specifically if the ACPI developers would produce ChangeLogs of the sort seen in kernel development. Andrew Grover replied:

Oops, web content a little stale...

Try checking out the acpi project page - You can d/l releases there and each release has a changelog.

As to development status:

Everything is code complete (more or less) EXCEPT:

If you're interested with following ACPI progress, I'd recommend subscribing to the acpi-devel mailing list.

Matthew Wilcox asked, "One thing I'm not clear about is status of support for ACPI 2.0. The FAQ on intel's website claims support for ACPI 1.0b only with 2.0 "in development", but it seems rather out of date." Andrew replied:

ACPI 2.0 introduced new objects as well as AML grammar elements.

The interpreter is ACPI 2.0 grammar compliant (modulo bugs). A separate matter is writing the code to take advantage of new objects.

We only take advantage of some ACPI 2.0 objects currently. (Indeed, we don't take advantage of all ACPI 1.0 objects.)

Examples of some ACPI 1.0 objects we use: thermal zones, battery, embedded controller

Examples of some ACPI 1.0 objects we don't use (yet): device power management, smart battery

Examples of some ACPI 2.0 objects we use: XSDT, ECDT, processor performance state objects

Examples of some ACPI 2.0 objects we don't use (yet): _PXM, _CST, _HPP

21. Syscalltrack 0.75 Released

13 Sep 2002 (1 post) Subject: "ANN: syscalltrack 0.75 "Boffing Hyrax" released"

Topics: SMP, User-Mode Linux

People: Muli Ben-YehudaMuli

Muli Ben-Yehuda announced:

syscalltrack-0.75, the 11th alpha release of the Linux kernel system call tracker, is now available. syscalltrack supports version 2.4.x of the Linux kernel on the i386 (UP and SMP) and UML architectures. 2.5.x kernel versions should work as well, but did not receive the same extensive testing. Kernel 2.2.x is NOT supported in this release, due to technical difficulties.

This release contains extensive autoconf support for easy installation (just './configure && make sudo make install' and you're all set) and support for 'kill process' and 'suspend process' actions. It also contains major bug fixes - upgrade is recommended.

* What is syscalltrack?

syscalltrack is made of a pair of Linux kernel modules and supporting user space environment which allow interception, logging and possibly taking action upon system calls that match user defined criteria. syscalltrack can operate either in "tweezers mode", where only very specific operations are tracked, such as "only track and log attempts to delete /etc/passwd", or in strace(1) compatible mode, where all of the supported system calls are traced. syscalltrack can do things that are impossible to do with the ptrace mechanism, because its core operates in kernel space.

* Where can I get it?

Information on syscalltrack is available on the project's homepage:, and in the project's file release.

The source for the latest version can be downloaded directly from: or any of the other sourceforge mirrors.

* Call for developers:

The syscalltrack project is looking for developers, both for kernel space and user space. If you want to join in on the fun, get in touch with us on the syscalltrack-hackers mailing list (

* License and NO Warrany

syscalltrack is Free Software, licensed under the GNU General Public License (GPL) version 2. The 'sct_ctrl_lib' library is licensed under the GNU Lesser General Public License (LGPL).

syscalltrack is in _alpha_ stages and comes with NO warranty. We put it through extensive testing and routinely run it on our systems, but if it breaks something, you get to keep all of the pieces.

* PGP Signature

All syscalltrack releases from now on will be signed. This release is signed with my pgp public key, which you can get from or via 'gpg --keyserver --recv-keys 0xBFD537CB'

Happy syscalltracking!


New in version 0.75, "Boffing Hyrax"

* This release contains complete autotools support for the entire syscalltrack system: kernel modules, libraries and applications. Download, run './configure && make && sudo make install' and everything should just work [famous last words]. The autotools support includes automatic kernel version detection (which can be overridden at configure time), correct user space compilation on the various linux distributions, correct kernel modules compilation (unlike the ad-hoc CFLAGS selection we had until now), support for UML and 2.5 kernels, a working install and uninstall target (sct_load, sct_config, sctrace, sct_unload are installed) and lots of other good stuff.

* This release also contains support for 'kill process' and 'suspend process' actions. Until now, all you could do was log system call invocations (that match a certain rule), or return error values from them. Now you can set rules to kill any process that matches a rule (tries to connect to a certain host, tries to delete a certain file, or just does getpid() *muhahaha*), or, if you're feeling kinder and gentler, just suspend it until you attach to it with a debugger.

* This release contains a fix a serious SMP race which would cause a system call to fail with -ENOSYS in certain cases.

* More system calls supported: shutdown, getsockname, getpeername, socketpair, send, sendto, recvfrom, shutdown, setsockopt, getsockopt, sendmsg, recvmsg. adjtimex, capset and capget, ptrace, stat64, lstat64 and fstat64.

* Fix a bug where bdflush() was incorrectly hijacked, leading to the bdflush system call not working correctly.

22. Test Arbitrary Patches On OSDL Machines

13 Sep 2002 (1 post) Subject: "[OSDL] VM_Regress test available on STP"

Topics: Virtual Memory

People: Cliff WhiteMel Gorman

Cliff White announced:

Mel Gorman's VM Regress tool is now available as an automated test on OSDL's Scalable Test Platform. ( or )

VM Regress project page:
Some sample results (2.4.18 kernel)

Please give us feedback on the test and STP.

23. Compliance With POSIX Threading Semantics

15 Sep 2002 - 16 Sep 2002 (10 posts) Subject: "[patch] thread-exec-2.5.34-B1, BK-curr"

Topics: POSIX, Version Control

People: Ingo MolnarLinus Torvalds

Ingo Molnar said:

the attached patch (against BK-curr + all my previous patches) implements one of the last missing POSIX threading details - exec() semantics. Previous kernels had code that tried to handle it, but that code had a number of disadvantages:

the patch adds the same logic, but extended with the following enhancements:

it would perhaps be a more generic approach to add a new syscall, sys_ungroup() - which would do largely what de_thread() does in this patch.

But it's not really needed now - posix_spawn() is currently implemented via starting a non-CLONE_THREAD helper thread that does a sys_exec(). There's no API currently that needs a direct exec() from a thread - but it could be created (such as pthread_exec_np()). It would have the advantage of not having to go through a helper thread, but the difference is minimal.

Linus Torvalds replied:

Ingo, can you create a test-case to verify that a new-style thread can sanely do

        if (!vfork())

which leaves the other threads alive and well and is reasonably efficient..

I don't personally much like the POSIX execve() behaviour, and I'd like to make sure that it can be avoided for cases where that makes sense (ie a threaded app that wants to start some other helper program should be able to do so).

Ingo agreed he didn't like those semantics; and said he'd verify "whether thread-specific exec() works via a helper thread (or vfork)." Linus remarked, "As long as it works with something sane (and vfork() is sane), I'm happy with the posix behaviour by default. After all, the execve() really _does_ need to "de-thread" anyway, and if we need to make that explicit (with the vfork()) then that's fine."

24. Linux 2.5.35 Released

15 Sep 2002 - 17 Sep 2002 (9 posts) Subject: "Linux 2.5.35"

Topics: Power Management: ACPI, USB, User-Mode Linux, Version Control

People: Linus TorvaldsJeff DikeAndrew MortonIngo Molnar

Linus Torvalds announced 2.5.35:

Hmm.. Lots of threading work by Ingo Molnar, more merges with Andrew Morton, and Rusty "trivial" Russell (because BK only holds one person responsible the trivial patches get attributed to the original author, not Rusty, but Rusty should get a special attribution for maintaining the set of patches).

Oh, and Jeff Dike's UML is in.

ACPI, PPC, USB, Sparc etc updates.

25. Zero-Copy NFS For 2.5.35

15 Sep 2002 (1 post) Subject: "[PATCH] zerocopy NFS for 2.5.35"

Topics: FS: NFS, FS: XFS

People: Hirokazu Takahashi

Hirokazu Takahashi announced:

I announce to have ported the patches for for zerocopy NFS against linux-2.5.35.

I added new feature that nfsd-write may use writev interface as writev is going to be faster than ever.

This feature can reduce not only cpu time but also overhead of allocating HUGE socket buffers for NFS write.

    This patch enables HW-checksum against outgoing packets including UDP frames.
    This patch makes sendfile systemcall over UDP work. It also supports UDP_CORK interface which is very similar to TCP_CORK. And you can call sendmsg/senfile with MSG_MORE flags over UDP sockets.
    This patch fixes the problem of x86 csum_partilal() routines which can't handle odd addressed buffers.
    This patch makes RPC can send some pieces of data and pages without copy.
    This patch makes NFSD send pages in pagecache directly when NFS clinets request file-read.
    nfsd_readdir can also send pages without copy.
    This patch makes per-cpu UDP sockets so that NFSD can send UDP frames on each prosessor simultaneously. Without the patch we can send only one UDP frame at the time as a UDP socket have to be locked during sending some pages to serialize them.
    This patch enables NFS-write uses writev interface. NFSd can handle NFS requests without reassembling IP fragments into one UDP frame.
    This patch makes writev for regular file work faster.

    Caution: XFS doesn't support writev interface yet. NFS write on XFS might slow down with No.8 patch. I wish SGI guys will implement it.

    If you don't want to use sendfile over UDP yet, you can apply it instead of No.1 and No.2 patches.

26. Support For The Southbridge via8235

16 Sep 2002 (2 posts) Subject: "via8235 support..."

People: Vojtech Pavlik

Someone asked if there were support for the southbridge via8235, and Vojtech Pavlik posted a complete driver against 2.4.19. End of thread.

27. IDE Oops Dumper 0.1 Released

16 Sep 2002 - 17 Sep 2002 (13 posts) Subject: "[PATCH] Experimental IDE oops dumper v0.1"

Topics: Debugging, Disks: IDE, FS

People: Rusty RussellAlan Cox

Rusty Russell posted a patch, gave a link to some userspace utitilites, and announced:

Been on my TODO list for a while, finally got around to polishing it off. Some work still to do before it can be included, but you get the idea.


From oopser-0.1/MOTIVATION:

The aim of this software is to make reporting kernel oopses possible for inexperienced users, in a way which doesn't violate their privacy by sending out information without their knowledge. The days of ever Linux user being able to set up a serial console have long gone.

The hope is that significant feedback will allow statistical analysis of hardware and software combinations, making the Linux Kernel more stable. Since most Linux users are on x86, with IDE disks, this is the first aim of the oops dumper.

*Any* crashes are bad, but users tend to ignore a once-a-month lockup (eg. panic while in X). Hopefully this code will allow some of those bug reports to make it back to us.

I hope that distribution vendors will pick this up, perhaps arming the module after noticing an unclean filesystem at boot (it does, after all, take about 60k to hold the compressed kernel symbols). I also ask that they coordinate with the Oops Team to arrange for a single public anonomyzed database where users and coders can query for problems.

Alan Cox had some specific complaints about the patch, and also remarked, "I like the infrastructure but the IDE dumper code is wishful thinking in one or two spots. You don't know f the controller is in DMA modes, tuned for different things to the drives or legacy free. Im not sure what to do for legacy free cases but the other bits like LBA48 and retuning probably can be handled with some small chipset specific hooks."

28. Benchmarking Tool 'contest' Version 0.30 Released

16 Sep 2002 (3 posts) Subject: "contest v0.30"

Topics: FS: ext3

People: Con KolivasCliff WhiteRik van Riel

Con Kolivas announced:

I've updated the "contest" responsiveness benchmark with many code cleanups by Rik Van Riel, and a more comprehensive readme. The actual benchmarks have not changed from v0.22 onwards. Previous versions were all slightly different because of bugs in the code. You can compare like with like from now on. Please don't use this to compare different hardware; it is unhelpful and the results will only confuse. Use it to compare kernels on the same hardware. I guess it could be used to compare filesystems (eg ext3 v reiser) with respect to the system maintaining responsiveness, but noone's attempted that yet. If anyone's got any other novel uses I'd love to hear them.

It now has a homepage:

Cliff White replied, "It looks neat, and i'd like to add it to the STP tests. I noticed you have hardcoded the '-j 4' Wouldn't it make more sense to adjust that to say, number_of_cpus * 2 or something?" But Rik van Riel said, "-j4 is nice for UP, since it sets the target CPU time for the compile to 80% (with one background job)."

29. JFS 1.0.22 Released

16 Sep 2002 (1 post) Subject: "[ANNOUNCE] Journaled File System (JFS) release 1.0.22"

Topics: Access Control Lists, Disk Arrays: EVMS, Extended Attributes, FS: JFS, Version Control

People: Steve Best

Steve Best announced:

Release 1.0.22 of JFS was made available today.

Drop 60 on September 16, 2002 (jfs-2.4-1.0.22.tar.gz and jfsutils-1.0.22.tar.gz) includes fixes to the file system and utilities.

There are two patches available to support ACLs, the first is JFS extended attributes (jfs-2.4-1.0.22-xattr.patch) the second is JFS ACLs (jfs-2.4-1.0.22-acl.patch).

Utilities changes

File System changes

For more details about JFS, please see the patch instructions or changelog.jfs files.

JFS for Linux

30. Linux 2.2.22 Released

16 Sep 2002 - 17 Sep 2002 (2 posts) Subject: "Linux 2.2.22"

Topics: Disk Arrays: RAID, Disks: IDE

People: Alan Cox

Alan Cox announced Linux 2.2.22. From the release notes:

Linux 2.2.22 is primarily an errata release backporting fixes for multiple small kernel errors found during auditing of the 2.4 code. 2.2 based users who have untrusted local users should update to this kernel.

In addition the kernel fixes some bugs in the HDLC layer and adds support for the newest 3ware IDE RAID cards.

Feature Updates

Kernel Bug Fixes

Security Fixes

31. Usermode Linux For 2.4.19 Released

16 Sep 2002 - 17 Sep 2002 (3 posts) Subject: "user-mode port 0.59-2.4.19-5"

Topics: Disks: SCSI, FS: procfs, User-Mode Linux

People: Jeff Dike

Jeff Dike announced:

This is the first major release of the 2.4.19 UML.

The major kernel changes since the last 2.4.18 UML include -

A number of honeypot and jail mode bugs and crashes were fixed.

Many build cleanups and fixes.

Many new exported symbols.

Added a new filesystem - hppfs (honeypot procfs), which allows UML /proc entries to be arbitrarily modified from the host

Fixed a number of crashes and one data corruption bug.

Much code cleanup, including starting to define a host OS interface, so that UML can become portable between OSes.

Many configuration cleanups, including splitting the large into smaller, more manageable config.ins.

Added /proc/mconsole, which allows UML processes to send mconsole notifications to mconsole clients on the host.

SCSI is now available. Currently, the only low-level driver is scsi_debug, which runs a SCSI ramdisk in 8M (by default) of kernel memory.

eth devices inside UML are now guaranteed to get the same names as were specified on the command line.

Fixed a number of block driver bugs, and cleaned it up some.

Helpers are now killed when UML exits, so host ports are released and telnet sessions ended cleanly.

The terminal emulator that UML uses is now configurable.

Fixed a number of gdb support bugs.

The major utilities changes include -

uml_moo now sparses its output files. It also has a destructive merge option and handles large COW files correctly.

Several tunctl bugs were fixed and some cleanups done.

There is now a jail kit, which contains everything needed to set up a chroot and run a UML confined to it.

There is also the host side of hppfs, including a small demo driver.

Downloads are available at

Other links of interest:

The UML project home page :
The UML Community site :

32. Linux Security Module 2.5.35-lsm1 Released

17 Sep 2002 (1 post) Subject: "[ANNOUNCE] 2.5.35-lsm1"

Topics: Networking, Security, Version Control

People: Chris WrightJohn LevonStephen Smalley

Chris Wright announced:

The Linux Security Modules project provides a lightweight, general purpose framework for access control. The LSM interface enables security policies to be developed as loadable kernel modules. See for more information.

2.5.35-lsm1 patch released. This is a rebase up to 2.5.35 as well as numerous module updates and bugfixes.

Full lsm-2.5 patch (LSM + all modules) is available at:

The whole ChangeLog for this release is at:

The LSM 2.5 BK tree can be pulled from:


33. Linux 2.5.36 Released; XFS Merged

17 Sep 2002 - 18 Sep 2002 (2 posts) Subject: "Linux 2.5.36"

Topics: Big Memory Support, Disks: IDE, FS: NTFS, FS: XFS, USB

People: Linus TorvaldsNathan Straz

Linus Torvalds announced 2.5.36:

Big patch, most of it due to the XFS merge.

The rest is pretty normal - more syncs with Andrew, some console code reorg by James, NTFS fixes for highmem, and IDE, USB and firewire updates.

To the news of the XFS merge, Nathan Straz said, "Woohoo!"

34. Kernel 2.5 Status Report For September 18

17 Sep 2002 - 18 Sep 2002 (7 posts) Subject: "[STATUS 2.5] September 18, 2002"

Topics: FS: XFS, POSIX, User-Mode Linux

People: Guillaume Boissiere

Guillaume Boissiere posted the 2.5 Status For September 18 and said:

Well, what a week! XFS (the journaling filesystem from SGI), UML (User-Mode Linux, that lets you run Linux inside Linux) and more POSIX threading work have been merged.

The latest kernel status update is on the Web at:

35. uCLinux 2.5.36-uc0 Released

18 Sep 2002 (1 post) Subject: "[PATCH]: linux-2.5.36uc0 (MMU-less support)"

People: Greg Ungerer

Greg Ungerer announced:

The latest MMU-less architecture support, based on linux-2.5.36, is up at the usual place:

36. Linux 2.4.20-pre7-ac1 Released

18 Sep 2002 (3 posts) Subject: "Linux 2.4.20-pre7-ac1"

Topics: PCI

People: Alan Cox

Alan Cox announced:

You can now load ide pci drivers at boot time or as modules. Don't try unloading the modules yet. Don't load them on an active device yet either.

My merge queue is currently 129 items long so there is a fair bit pending for pre7-ac2







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.