Kernel Traffic #240 For 10�Nov�2003

There is no 2.6 version of kgdb currently. The 2.4 version also has some problems that makes it better to not use it at all.

My plan was to do a fresh port from the code in -mm* and get rid of many of the ugly hacks in 2.4. Doing this properly requires adding dwarf2 annotation to entry.S and other assembly files. This would allow to get rid of the "interrupt threads" hack in 2.4 because gdb could directly backtrace through exception/interrupts.

Here goes -pre8... It contains a quite big amount of ACPI fixes, networking changes, network driver changes, few IDE fixes, SPARC merge, SH merge, tmpfs fixes, NFS fixes, important VM typo fix, amongst others.

People seeing boot IDE related crashes on Alpha with previous kernels please try this.

Those are the same symptoms I saw in test7, fixed by:

http://marc.theaimsgroup.com/?l=linux-kernel&m=106606272103414&w=2

Patrick, were you going to submit your patch to resolve this? I'm thinking this kind of problem would meet Linus's test10 integration criteria.

(That's not an APM problem, it's a generic PM problem that'd show up with swsusp too. And likely even some ACPI systems.)

Ok, 2.6.0-test9 is out there in all the normal places..

First off, I have to say that this week has been a lot better than last week. I've been cursing at some developers a _lot_ less: while a lot of people wanted to sync up with me after the -test7 "stability freeze" announcements with stuff that wasn't really about stability, that dropped off a lot this week, and I didn't have to be rude to people very much at all.

There's some XFS and cifs updates here, but even they were pretty benign and largely just bugfixes. Oh, and the SATA driver got included, which you either disable or which allows people to use modern hardware.

Anyway, while I've been happy with the progress from -test7, I want to see this total stability freeze work even better. The test9 patch is about 120kB compressed - which is small for a week of work, but is still more than I want to see before a stable release.

So guys, let's work on this even more for test10. I'm going to _totally_ ignore patches that aren't for major bugs. Don't send me anything that _others_ wouldn't consider horribly critical.

In other words, even if you think that something is the most important piece of software in the world, if you can't make aunt Tilly up the street say "oh, but that would be a show-stopper", then don't bother sending it to me.

If it corrupts data, is a security issue, or causes lockups or just basic nonworkingness: and this happens on hardware that _normal_ people are expected to have, then it's critical. Otherwise, it's noise and should wait.

If this works out, then I'll submit -test10 to Andrew Morton, and if he takes it we'll probably have a real 2.6.0 after a final shakedown. So try to help, please. We'll all be happier.

There are things that I bet Andrew will be willing to apply to -STABLE: things like architecture updates etc that clearly fix stuff. But right now I want to avoid even that kind of noise: if it doesn't clearly help _testing_ of stability, I'm just not interested at this point.

So for example, in the last week I just dropped some S390 updates without even looking at them. It was too late - and even if they fix bugs, I don't see that applying those patches simply would matter for 2.6.0 any more.

So for example: I am pretty happy with how the size of the -test8 and -test9 patches have been shrinking, but even -test9 was big enough that I couldn't say that we're clearly "asymptotically approaching a stable kernel". At some point "noise patches" are bad if only because they make it less clear what the general status of the tree is.

In particular, if the 2.6.0-test10 patch is just 30kB compressed, and I can just page through it with "less" and see that every single small part of the patch was pretty clear and not something really scary, I'll be a _lot_ happier about passing the thing off to Andrew. In contrast, if the patch is full of stuff that isn't really obvious, I'm going to be less happy, and worry more about what the side effects are.

I've just completed a second revision of my "Wonderful World of Linux 2.6" document that I mailed around back in July. This document is my reasonably complete list of the new features in Linux 2.6, with explanations. This one covers up to the -test9 kernel released yesterday and takes into consideration a lot of feedback from members of the list and elsewhere. The also has large portions rewritten for flow, etc.

If you read the previous one, there actually haven't been that many big changes since -test1. If you just want to see (some of) the changes, I made a rough list at http://kniggit.net/wwol26-changes.html.

If you haven't read the previous one (or even if you have), I have posted the update at http://kniggit.net/wwol26.html. (Text version: http://kniggit.net/wwol26.txt)

Please let me know what you think. I am hopeful that this will be a good resource for people to use for learning about Linux 2.6. Unless there's some severe inaccuracies, I probably won't be updating this again until the official 2.6 release is out.

netdev@oss.sgi.com doesn't have an official webpage anywhere to tell you that it even exists. No info on how to subscribe or what the rules of the list are.

On http://oss.sgi.com/ the netdev list is not mentioned at all.

I can't find a mailinglist archive of netdev.

I'd like to read netdev but I'm not sure to subscribe since as I said info on it is basically non-existing.

Perhaps SGI could create a "netdev" page somewhere on oss.sgi.com, link to it from "projects lists" or "newsgroups and mailinglists", and resurrect the archive ? Please ?

I generalised it to remove a ton of nasty 440GX hacks and also make the code smaller by swapping a big table for little __init functions. I sent akpm comments on it but I never did a 2.6 version directly. Its the same code in both cases however.

Right now I have exams, which is why I'm reading email not revising ;)

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm1

• kernel.org is being slow - the diff is also at

  http://www.zip.com.au/~akpm/linux/patches/2.6.0-test9-mm1.gz

• A couple of fixes for VM memory reclaim.
• The ia32 EFI code seems to be complete now.
• The recent IO scheduler regressions should be fixed.
• Dropped the runtime-selectable-IO-scheduler patches.
• A number of fixes to the pagecache readahead code should help seeky workloads such as non-direct-io databases.
• Various fixes, mostly minor.

Here goes -pre9. Only bugfixes will be accepted till 2.4.24-pre now.

-pre9 backouts out a few ACPI problematic changes. It also includes a USB update, JFS update, sis900/starfire/tg3 bugfixes, etc.

ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.4

modutils-2.4.26.tar.gz          Source tarball, includes RPM spec file
modutils-2.4.26-1.src.rpm       As above, in SRPM format
modutils-2.4.26-1.i386.rpm      Compiled with gcc 2.96 20000731, glibc 2.2.2.
modutils-2.4.26-1.ia64.rpm      Compiled with gcc 2.96-ia64-20000731, glibc-2.2.3.
patch-modutils-2.4.26.gz        Patch from modutils 2.4.25 to 2.4.26.

Changelog extract

• Ignore SHT_MIPS_DWARF sections. Alvaro Martinez Echevarria.
• Add -malign-double to cflags for 64 bit builds.
• Fix zlib linking problems. Maciej W. Rozycki.
• Remove hard coded limits on length of modules.conf lines.
• Alias updates. Red Hat.
• Makefile fix for parallel build using bison. Andreas Haumer.
• Document difference between patterns and modules in modprobe. Frank Murphy.
• Suppress module not found message on modprobe -q. Frank Murphy.
• Add module name to some messages. Red Hat.
• Add amd64 support. i386 now defaults to combined 32/64 bit. Arnd Bergmann.
• Older glibc versions had a wrong name for R_390_GOTOFF32. Arnd Bergmann.
• Run known directories in the correct historical order. Red Hat.
• Upgrade config.sub, config.guess to glibc 2.3.2.
• Add sh64 support. Benedict Gaster.
• Only build sys_oim.o when COMPAT_2_0 is set, it breaks with ia64 and recent glibc.

Release 1.1.4 of JFS was made available today.

Drop 67 on October 30, 2003 includes fixes to the file system and utilities.

Utilities changes

• Work around gcc 2.95 bug
• Handle log full without crashing
• Message format fix

File System changes

• Make sure journal buffer gets flushed to disk
• Improved error handling
• Remove racy, redundant call to block_flushpage
• Fix race between link() and unlink()

Note: The 2.4.23 and 2.6 kernel.org development kernels are kept up to date with the latest JFS code. The file system updates available on the web site are only needed for maintaining earlier 2.4 kernels.

For more details about JFS, please see our website: http://oss.software.ibm.com/jfs

The 54k patch at http://ftp.linux.org.uk/pub/linux/willy/patches/fs-const.diff makes many file_operations, dentry_operations, address_space_operations, inode_operations, super_operations and dquot_operations const.

This was inspired by intermezzo doing something naughty which the compiler didn't know to warn about. By making these pointers point to const structs, the compiler knows we shouldn't be doing that and will issue a warning.

As a bonus for the embedded people, this enables us to move more of the kernel into ROMmable sections. I've only done this for ext2 and a few well-known *_operations in this patch, but it could be done to many more filesystems. It only saves a few hundred bytes per filesystem, but it all adds up.

I've released a new snapshot of the uClinux/ColdFire toolchain based on GCC 3.3.2 and GCC 3.4-prerelease:

http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/gcc-3/

This release incorporares quite a lot of updates and fixes since the last official announcement.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm2/

• Various random fixes. Maybe about half of these are 2.6.0-worthy.

• Some improvements to the anticipatory IO scheduler and more readahead tweaks should help some of those database benchmarks.

  The anticipatory scheduler is still a bit behind the deadline scheduler in these random seeky loads - it most likely always will be.

• "A new driver for the ethernet interface of the NVIDIA nForce chipset, licensed under GPL."

  Testing of this would be appreciated. Send any reports to linux-kernel or netdev@oss.sgi.com and Manfred will scoop them up, thanks.

• I shall be offline for a couple of days.

Somebody has modified the CVS tree on kernel.bkbits.net directly. Dave looked at the machine and it looked like someone may have been trying to break in and do it.

We've fixed the file in question, the conversion is done back here at BitMover and after we transfer the files we check them and make sure they are OK and this file got flagged.

The CVS tree is fine, you might want to remove and update exit.c to make sure you have the current version in your tree however.

The problem file is kernel/exit.c which has a few extra entries like so:

    revision 1.121
    date: 2003/11/04 16:44:19;  author: davem;  state: Exp;  lines: +58 -0
    Oops, I worked on the  the wrong file, fixed again.
    ----------------------------
    revision 1.120
    date: 2003/11/04 16:42:00;  author: davem;  state: Exp;  lines: +0 -58
    *** empty log message ***
    ----------------------------
    revision 1.119
    date: 2003/11/04 16:22:47;  author: davem;  state: Exp;  lines: +2 -0
    *** empty log message ***
    ----------------------------
    revision 1.118
    date: 2003/10/27 19:50:03;  author: torvalds;  state: Exp;  lines: +11 -5
    Fix ZOMBIE race with self-reaping threads.

    exit_notify() used to leave a window open when a thread
    died that made the thread visible as a ZOMBIE even though
    the thread reaped itself. This closes that window by marking
    the thread DEAD within the tasklist_lock.

    (Logical change 1.14141)
    ----------------------------

Notice how the top 3 do not have the (Logical change X.YZ) at the end? That is a pointer so you can figure out the changeset boundaries and it is added back here during the conversion process. The file here is fine which leads me to believe that someone modified the file either on kernel.bkbits.net or managed to get in through the pserver. Dave swears up and down that it wasn't him so if anyone can step forward and claim responsibility that would be nice.

It's not a big deal, we catch stuff like this, but it's annoying to the CVS users.

No. There are two ways to get into a kernel release: patches to me by email (which depending on the person get more or less detailed scrutiny, but core files would definitely get a read-through and need an explanation), and through BK merges.

And the people who merge with BK wouldn't have used the CVS tree.

BK really needs to add per-changeset digital signatures, and I've been bugging Larry about this for years. :-) And there's a similar risk involving a subtle patch that claims to fix a bug, but really opens up a security hole. Someone clever enough to send a "patch" to Linus, who can forge sufficient mail headers that he doesn't notice --- and perhaps even forge a cc to the LKML, even though it never got sent there, might be able to sneak such a minor change into the master sources. This is especially true if the trojan horse gets burried in a number of other plausible changes, and had an SMTP from field that appeared to come from a trusted kernel developer.

An argument might be made that all patches sent to Linus should be at a minimum be GPG signed, but that assumes that Linus would be willing to use GPG, or is willing to have his mail reader set upt to do automatic GPG verification. One of the reasons why I think integration with BK would be a Good Thing is that (a) it becomes automatic, and (b) instead of it being verified only by Linus when he receives the patch, I or anyone else can verify the digital signature on each changeset whenever we want. This distributed verfication is very powerful, and hopefully this points out why we badly need such a capability.

We have released libsysfs v0.3.0 as part of the sysfsutils package.

The package can be downloaded from http://linux-diag.sourceforge.net/

Changes include:

• Support for the "block" subsystem. Block now is considered as a sysfs "class".
• Facility to build both shared and static libraries
• Fixed "write" attribute support.
• Added few "test" routines to demonstrate API usage.
• Headers now get installed to /usr/include/sysfs
• PCI name decode support.

Comments, suggestions and contributions welcome. The mailing list for discussing libsysfs and other diagnostic utilities is

http://lists.sourceforge.net/lists/listinfo/linux-diag-devel

The Linux Test Project test suite <http://www.linuxtestproject.org> has been released. The latest version of the testsuite contains 2000+ tests for the Linux OS. Our web site also contains other information such as: test results, a Linux test tools matrix, an area for keeping up with fixes for known blocking problems in the 2.5/2.6 kernel releases, technical papers and HowTos on Linux testing, and a code coverage analysis tool.

Highlights:

• Updated the LTP stress script to record 'iostat' statistics if needed.
• Updated the SCTP tests to support the current SCTP 2.6 kernel code.
• Added new NFS test, nfs04, to help test data integrity during copies across mounts.
• Applied more bug fixes, patches, and code cleanups.

We encourage the community to post results, patches or new tests on our mailing list <ltp-list@lists.sf.net> and use the CVS bug tracking facility to report problems that you might encounter with the test suite.