This issue of Kernel Traffic is dedicated to Mildred Brown, Sept 23, 1908 - March 5, 2002. Happy birthday!
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).
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..
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.
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://thebsh.namesys.com/bk/reiser3-linux-2.4. 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.
Adrian Bunk posted a 2.4 patch to add Configure.help 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.
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:
- Can I safely assume that, for all normal files named X in driverfs, that they have the exact same format and purpose?
- The "resource" files export resource structs, however the flags member of the struct uses bits that aren't exported by the kernel and are likely to change in the future. Also, some of the flags bits are reserved for use by the bus that the resource lives on, but the bus type isn't specified by the resource file, which requires the app to parse the path name in order to figure out which bus the resource refers to.
- "name" isn't particularly consistent. Sometimes it requires parsing to be useful ("PCI device 1234:1234", "USB device 1234:1234", etc.", sometimes it's the actual device name, sometimes it's something strange like "Hub/Port Status Changes".
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. :)
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 http://caldera.com/developers/community/contrib/aim.html.
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.
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.
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
- Fix ALi OOPS on RLX blades (Dan Eaton)
- Finish up ide pci register code (me)
- Switch IDE PCI drivers to use new register code (me)
- Fix scribble over constant data in hpt34x (me)
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:
http://users.pandora.be/bart.de.schuymer/ebtables/v2.0/ebtables-v2.0_vs_2.5.34.diff or, gzipped:
http://users.pandora.be/bart.de.schuymer/ebtables/v2.0/ebtables-v2.0_vs_2.5.34.diff.gzIt 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
http://users.pandora.be/bart.de.schuymer/ebtables/
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.
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.
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.
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?
- non-detached tasks will perform one more context switch, from the parent to the exiting thread.
- on SMP there's no wait_task_inactive() looping done by the parent anymore.
- the exit codepath became much more robust, eg. the procfs dput() potential scheduling causes no problems. We can actually perform some final cleanups after the parent thread has been notified.
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.
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
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.34-1.bz2For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.htmlOther links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
Andrew Morton replied, And Linus has merged it.
Congratulations, Jeff.
Jeff replied, Thanks!
It's great to finally have it in.
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 http://www.tux.org/lkml/
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 <linux-kernel@vger.kernel.org>
Post anything related to Linux kernel here, but nothing else :-)
Jan Kara <jack@suse.cz> [22 aug 2002]
quota subsystem maintainer
Paul Larson <plars@linuxtestproject.org> [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 <engebret@vnet.ibm.com> [15 aug 2002]
PPC64 architecture maintainer. Please send PPC64 patches to me
and our mailing list at <linuxppc64-dev@lists.linuxppc.org>
Ingo Molnar <mingo@elte.hu> [30 jul 2002]
Ingo wrote the new scheduler for 2.5.
Ralf Baechle <ralf@uni-koblenz.de> [30 jul 2002]
I am maintainer of the AX.25 code
Victor Yodaiken <yodaiken@fsmlabs.com> [30 jul 2002]
RTLinux patches, updates, contributions, drivers.
Please send first to the list: rtl@rtlinux.org
Pavel Machek <pavel@ucw.cz> [27 jul 2002]
I am network block device maintainer. Visit http://nbd.sf.net.
(see Steven Whitehouse <steve@gw.chygwyn.com> entry)
I am working on software suspend.
William Irwin <wli@holomorphy.com> [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 <riel@surriel.com>
Andrea Arcangeli <andrea@suse.de>
Martin Bligh <Martin.Bligh@us.ibm.com>
Andrew Morton <akpm@zip.com.au>
Dave Jones <davej@suse.de> [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 <andre@linux-ide.org> [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 <andrea@suse.de> [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 <Martin.Bligh@us.ibm.com> entry
Mail also:
Arjan van de Ven <arjanv@redhat.com>
Martin J. Bligh <Martin.Bligh@us.ibm.com> [28 mar 2002]
I'm interested in VM issues with lots (>4G for i386)
of RAM, lots of CPUs, NUMA
Steven Whitehouse <steve@chygwyn.com> [27 mar 2002]
I am the Linux DECnet network stack maintainer
Visit http://www.chygwyn.com/decnet/
Arnaldo Carvalho de Melo <acme@conectiva.com.br> [26 mar 2002]
IPX, 802.2 LLC, NetBEUI, http://kerneljanitors.org,
cyclom2x sync card driver
John Cagle <jcagle@kernel.org> [19 mar 2002]
The current maintainer of devices.txt, the list of
assigned device numbers for LANANA. Consult the web
site (www.lanana.org) for instructions on submitting
requests for new device numbers. Send all device
related email to <device@lanana.org>.
Tigran Aivazian <tigran@veritas.com>
I am author and maintainer of BFS filesystem and IA32
microcode update driver.
Rogier Wolff <R.E.Wolff@BitWizard.nl> [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 <martin@dalecki.de> [11 mar 2002]
IDE subsystem maintainer for 2.5
(mail Vojtech Pavlik <vojtech@suse.cz> too)
Ed Vance <serial24@macrolink.com> [05 mar 2002]
Maintainer for the generic serial driver, serial.c,
for 2.2 and 2.4 kernels. Please post patches to
linux-serial@vger.kernel.org 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 serial24@macrolink.com
netfilter/iptables development <netfilter-devel@lists.samba.org> [23 feb 2002]
Please report all netfilter/iptables related problems
to this mailinglist, where all netfilter developers are present.
See also http://www.netfilter.org/contact.html
Hans Reiser <reiser@namesys.com> [16 feb 2002]
Send me all reiserfs related patches with a cc to
reiserfs-dev@namesys.com, send bug reports to
reiserfs-dev@namesys.com, send paid support requests to
support@namesys.com after going to www.namesys.com/support.html
to pay, send discussions (not bug reports unless they are
interesting to most persons) to reiserfs-list@namesys.com.
If we sit on your patch for a week without responding,
yell at us, we deserve it. Look at our web page
at www.namesys.com for more about sending us code,
working with us, and our patch submission and tracking system.
Paul Bristow <paul@paulbristow.net> [16 feb 2002]
I am an ide-floppy driver maintainer
(ATAPI ZIP, LS-120/240 Superdisk, Clik! drives).
Mike Phillips <phillim2@comcast.net> [15 feb 2002]
Token ring subsystem and drivers.
Anton Altaparmakov <aia21@cam.ac.uk> [15 feb 2002]
I am the NTFS guy.
https://bugzilla.redhat.com/bugzilla [14 feb 2002]
Reports of problems with the Red Hat shipped kernels.
Alan Cox <alan@lxorguk.ukuu.org.uk> [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 <rml@tech9.net> [14 feb 2002]
Preemptible kernel is mine.
ALSA development <alsa-devel@alsa-project.org> [12 feb 2002]
Jaroslav Kysela <perex@perex.cz> [12 feb 2002]
Advanced Linux Sound Architecture
ALSA patches are available at
ftp://ftp.alsa-project.org/pub/kernel-patches/*
Neil Brown <neilb@cse.unsw.edu.au> [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 <maxk@qualcomm.com> [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 <riel@conectiva.com.br> [07 feb 2002]
Send me VM related stuff, please CC to linux-mm@kvack.org
Geert Uytterhoeven <geert@linux-m68k.org> [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 <hpa@zytor.com> [07 feb 2002]
i386 boot and feature code, i386 boot protocol, autofs3,
compressed iso9660 (but I'll accept all iso9660-related
changes.) kernel.org site manager; please contact me
for sponsorship-related issues.
kernel.org admins <ftpadmin@kernel.org> [07 feb 2002]
Kernel.org 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 <greg@kroah.com> [07 feb 2002]
I am USB and PCI Hotplug maintainer.
Trond Myklebust <trond.myklebust@fys.uio.no> [07 feb 2002]
I am NFS client maintainer.
James Simmons <jsimmons@transvirtual.com> [07 feb 2002]
Console and framebuffer sybsustems.
I also play around with the input layer.
Richard Gooch <rgooch@atnf.csiro.au> [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 <rmk@arm.linux.org.uk> [06 feb 2002]
ARM architecture maintainer. Please send all ARM patches through
the patch system at http://www.arm.linux.org.uk/developer/patches/
New serial drivers maintainer for 2.5. Submit patches to
rmk+serial@arm.linux.org.uk
Andrew Morton <akpm@zip.com.au> [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 <vandrove@vc.cvut.cz> [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 <reiserfs-dev@namesys.com> [05 feb 2002]
Send all reiserfs-related stuff here including but not limited to bug
reports, fixes, suggestions.
Oleg Drokin <green@linuxhacker.ru> [05 feb 2002]
SA11x0 USB-ethernet and SA11x0 watchdog are mine.
Vojtech Pavlik <vojtech@ucw.cz> [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 <ralf@gnu.org> [27 mar 2002]
I am mips/mips64 maintainer.
David S. Miller <davem@redhat.com> [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 <urban@teststation.com> [13 feb 2002]
smbfs
Jeff Garzik <jgarzik@mandrakesoft.com> [12 feb 2002]
I am the network-card-drivers guy (8139 for instance).
CC me and Andrew Morton <akpm@zip.com.au> on network driver patches.
video4linux list <video4linux-list@redhat.com> [12 feb 2002]
Gerd Knorr <kraxel@bytesex.org> [12 feb 2002]
video4linux
Tim Waugh <twaugh@redhat.com> [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 <viro@math.psu.edu> [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 <esr@thyrsus.com> [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 (Configure.help).
G?rard Roudier <groudier@free.fr> [5 feb 2002]
I am SCSI guy.
Jens Axboe <axboe@suse.de> [5 feb 2002]
I am block device subsystem maintainer.
Keith Owens <kaos@ocs.com.au> [5 feb 2002]
ksymoops, kbuild, .. .. .. .. . are mine.
Linus Torvalds <torvalds@transmeta.com> [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 <davej@suse.de>,
see his entry). Sorry, I can't do everything.
Marcelo Tosatti <marcelo@conectiva.com.br> [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 <alan@lxorguk.ukuu.org.uk>,
- Rusty Russell <trivial@rustcorp.com.au>.
Rusty Russell <rusty@rustcorp.com.au> [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 trivial@rustcorp.com.au.
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 ============================================ <akpm@digeo.com>: o Sync up syscall table with 2.5 <alan@redhat.com>: o fix ramdisk cache flush <fzago@austin.rr.com>: o [PATCH] (repost) fix for big endian machines in scanner.c <hch@lst.de>: o inline grab_cache_page o cleanup try_to_free_pages naming o fix syscall prototypes in init/do_mounts.c <mlang@delysid.org>: o HandyTech HandyLink patch <paulus@au1.ibm.com>: o PPC32: Add extended attributes syscalls <proski@gnu.org>: o 2.4.20-pre6: befs still not in fs/Makefile <ralf@dea.linux-mips.net>: 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 <thockin@freakshow.cobalt.com>: o NVRAM driver <zwane@mwaikambo.name>: o trivial ohci fixes Adrian Bunk <bunk@fs.tum.de>: o Configure.help entry for the ForteMedia FM801 driver o add Configure.help entries for CONFIG_USB_SERIAL_KEYSPAN_USA19Q{W,I} Bjorn Helgaas <bjorn_helgaas@hp.com>: o IA64 sync Dave Kleikamp <shaggy@kleikamp.austin.ibm.com>: o JFS: add permission checks before getting or setting xattrs David Brownell <david-b@pacbell.net>: o usbcore updates Geert Uytterhoeven <geert@linux-m68k.org>: o M68k extended attributes o Fixup fbcon build Greg Kroah-Hartman <greg@kroah.com>: o USB serial: added device path to the proc file now that usb_make_path() is available Ivan Kokshaysky <ink@jurassic.park.msu.ru>: o transparent pci-pci bridges fix o alpha rwsem update Jean Tourrilhes <jt@bougret.hpl.hp.com>: o Fix stupid compile error in wavelan_cs Jeff Garzik <jgarzik@mandrakesoft.com>: o Add kernel-related BitKeeper docs/scripts, as found in the 2.5.x kernel Documentation/BK-usage sub-directory. Maksim Krasnyanskiy <maxk@qualcomm.com>: o 2.4.20-pre6 Bluetooth core fixes Marcelo Tosatti <marcelo@plucky.distro.conectiva>: 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 <oliver@neukum.name>: o new ids for hpusbscsi Paul Mackerras <paulus@samba.org>: 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 <elenstev@mesatop.com>: o Configure.help fix for CONFIG_IP_NF_MATCH_DSCP
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 configure.help states that you should put a 'Y' if unsure.
The patch is for 2.4.19.
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. ;)
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).
Marc Giger asked about the status of ACPI in 2.4 and 2.5 kernels. He complained that http://acpi.sourceforge.net/ 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 sf.net acpi project page - sf.net/projects/acpi. You can d/l releases there and each release has a changelog.
As to development status:
Everything is code complete (more or less) EXCEPT:
- S3/S4 support
- userspace library
- using ACPI for device PnP and resource determination
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
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: http://syscalltrack.sourceforge.net, and in the project's file release.
The source for the latest version can be downloaded directly from: http://osdn.dl.sourceforge.net/sourceforge/syscalltrack/syscalltrack-0.75.tar.gz 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 (http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers).
* 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 http://vipe.technion.ac.il/~mulix/pubkey.asc or via 'gpg --keyserver wwwkeys.pgp.net --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.
Cliff White announced:
Mel Gorman's VM Regress tool is now available as an automated test on OSDL's Scalable Test Platform. (http://www.osdl.org/stp or http://sourceforge.net/projects/stp )
VM Regress project page: http://www.csn.ul.ie/~mel/projects/vmregress/
Some sample results (2.4.18 kernel) http://khack.osdl.org/stp/5210Please give us feedback on the test and STP.
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:
- it only worked if the exec()-ing thread was the thread group leader, creating an assymetry. This does not work if the thread group leader has exited already.
- it was racy: it sent a SIGKILL to every thread in the group but did not wait for them to actually process the SIGKILL. It did a yield() but that is not enough. All 'other' threads have to finish processing before we can continue with the exec().
the patch adds the same logic, but extended with the following enhancements:
- works from non-leader threads just as much as the thread group leader.
- waits for all other threads to exit before continuing with the exec().
- reuses the PID of the group.
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()) execve(); thread_exit();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.
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.
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.
- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va10-hwchecksum-2.5.35.patch
This patch enables HW-checksum against outgoing packets including UDP frames.- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va11-udpsendfile-2.5.35.patch
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.- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va-csumpartial-fix-2.5.35.patch
This patch fixes the problem of x86 csum_partilal() routines which can't handle odd addressed buffers.- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va01-zerocopy-rpc-2.5.35.patch
This patch makes RPC can send some pieces of data and pages without copy.- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va02-zerocopy-nfsdread-2.5.35.patch
This patch makes NFSD send pages in pagecache directly when NFS clinets request file-read.- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va03-zerocopy-nfsdreaddir-2.5.35.patch
nfsd_readdir can also send pages without copy.- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va04-zerocopy-shadowsock-2.5.35.patch
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.- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va05-zerocopy-nfsdwrite-2.5.35.patch
This patch enables NFS-write uses writev interface. NFSd can handle NFS requests without reassembling IP fragments into one UDP frame.ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va06-writev-2.5.35.patch
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.
- ftp://ftp.valinux.co.jp/pub/people/taka/2.5.35/va09-zerocopy-tempsendto-2.5.35.patch
If you don't want to use sendfile over UDP yet, you can apply it instead of No.1 and No.2 patches.
Someone asked if there were support for the southbridge via8235, and Vojtech Pavlik posted a complete driver against 2.4.19. End of thread.
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.
Rusty.
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.
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:
http://contest.kolivas.net
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).
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
- add jfs_tune utility (see jfs_tune man page for details) jfs_tune allows users to:
- attach a JFS external journal to a JFS file system
- set/change volume label, UUID of JFS file system and external log devices
- view superblock information of JFS file system and external log devices
- add option '-J journal_device' to mkfs.jfs to create an external journal only and optionally set its volume label (see mkfs.jfs man page)
- add option '-J device=' to mkfs.jfs to attach an existing JFS external journal to the JFS file system that will be created (see mkfs.jfs man page)
- fix mkfs.jfs to store 16 character volume labels properly
- code cleaup
- add extend support to JFS FSIM for EVMS (see http://sourceforge.net/projects/evms/)
File System changes
- Use strtoul instead of strtoull
- Add write_super_lockfs & unlock_fs used for snapshot
- rework extent invalidation
- cosmetic changes to reduce the diff to the bitkeeper tree
- backport lmLogWait from 2.5
- Remove unused jfs_extendfs.h
- use buffer_heads to access the superblock
- ifdef out unused functions related to partial blocks
- sync the block device on umount or r/o remount
- remove superfluous includes
For more details about JFS, please see the patch instructions or changelog.jfs files.
JFS for Linux http://oss.software.ibm.com/jfs
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
- Support for newest 3ware IDE RAID
- Set accessed time on AF_UNIX sockets
Kernel Bug Fixes
- Fix isofs over loopback in 2.2
- Send SIGIO on socket shutdown
- Correct out of memory socket error reporting
- Fix handling of buffer internal pointers in HDLC
- Correct order of neighbour sending
- Identify VIA C3 processors properly
- Fix netlink/ipfw error handling path
- Fix Alpha ptrace
Security Fixes
- Multiple numbers of potential sign handling, maths overflow and casting errors were fixed. Some of them are theoretically locally exploitable. No remote holes were found.
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 config.in 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 http://user-mode-linux.sourceforge.net/dl-sf.html
Other links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
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 http://lsm.immunix.org 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:
http://lsm.immunix.org/patches/2.5/2.5.35/patch-2.5.35-lsm1.gzThe whole ChangeLog for this release is at:
http://lsm.immunix.org/patches/2.5/2.5.35/ChangeLog-2.5.35-lsm1The LSM 2.5 BK tree can be pulled from:
bk://lsm.bkbits.net/lsm-2.52.5.35-lsm1
- merge with 2.5.31-35 (me)
- fix dnotify_struct leak (John Levon)
- added hooks for labelling during TCP passive open (Wayne Salamon)
- LIDS: update file open permission; compile fixes. (Huagang Xie)
- SELinux: ipc_permission fix (Stephen Smalley)
- SELinux: selopt fixes (Wayne Salamon)
- SELinux: sysctl updates (Stephen Smalley)
- update TCP passive open hook (Wayne Salamon)
- SELinux: rework sock security field usage (Wayne Salamon)
- SELinux: __FUNCTION__ fixes (Stephen Smalley)
- SELinux: bug fixes (audit and constaint evaluation) (Stephen Smalley)
- LIDS: __FUNCTION__ fixes (me)
- DTE: update to proper tasklist locking and iterators (me)
- LIDS: use new tasklist iterators (me)
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!
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:
http://www.kernelnewbies.org/status/
Greg Ungerer announced:
The latest MMU-less architecture support, based on linux-2.5.36, is up at the usual place:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.36uc0.patch.gz
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