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 #258 For 18 Apr 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1917 posts in 9538K.

There were 478 different contributors. 245 posted more than once. 192 posted last week too.

The top posters of the week were:

1. Marc-Christian Petersen New 2.2 Maintainer; Linux 2.2.26 Released

24 Feb 2004 - 26 Feb 2004 (2 posts) Archive Link: "Linux 2.2.26 aka "2.2 is not dead" released"

People: Marc-Christian PetersenAlan Cox

Marc-Christian Petersen, taking over from Alan Cox as 2.2 maintainer, released 2.2.26, saying:

I am very proud to announce this because it fixes several of security bugs including the last mremap() bug, the longer known hashing exploit possibility in the network stack and /dev/rtc leakage.

I encourage all 2.2 kernel users to update.

Please send me all fixes/patches/etc. I've forgotton for 2.2.27-pre/rc inclusion.

2. New PRAMFS RAM-Based Filesystem; Free For GPLed Projects

3 Mar 2004 - 18 Mar 2004 (17 posts) Archive Link: "new special filesystem for consideration in 2.6/2.7"

Topics: FS: ramfs, Patents, Small Systems

People: Steve LongerbeamDave JonesMike Fedyk

Steve Longerbeam said:

MontaVista Software has developed a new filesystem targeted for embedded systems that we would like to have considered for inclusion in 2.6 or 2.7. It is called the Protected and Persistent RAM Special Filesystem (PRAMFS). It was originally developed for three major consumer electronics companies for use in their smart cell phones and other consumer devices.

An intro to PRAMFS along with a technical specification is at the SourceForge project web page at A patch for 2.6.3 has been released at the SF project site.

PRAMFS can be tested on a desktop by reserving some portion of physical memory with "mem=". For example, a machine with 512M could reserve the top 32M with "mem=480M". PRAMFS would then be mounted with:

mount -t pramfs -o physaddr=0x1e000000,init=0x2000000 none /mnt/pramfs

He posted some introductory docs, and Dave Jones pointed out, "the biggest thing holding back inclusion of this is likely the comment about there likely being patents held on parts of that code." Steve replied, "MV has a patent pending, but it would only affect any future use of the technology in a _non GPL_ operating system. Used in Linux or any future GPL software, no patent licenses or royalties are involved at all." Mike Fedyk said that this should be put into legal terms, and included in the patch itself. Tim Bird pointed out that there was such a notice at the top of every file in the patch, reading:

"This software is being distributed under the terms of the GNU General Public License version 2. Some or all of the technology encompassed by this software may be subject to one or more patents pending as of the date of this notice. No additional patent license will be required for GPL implementations of the technology. If you want to create a non-GPL implementation of the technology encompassed by this software, please contact for details including licensing terms and fees."

3. Status Of Software Suspend

12 Mar 2004 - 18 Mar 2004 (17 posts) Archive Link: "Dealing with swsusp vs. pmdisk"

Topics: Big Memory Support, Compression, Software Suspend, Version Control

People: Pavel MachekTheodore Ts'oJan RychterBenjamin Herrenschmidt

Pavel Machek said:

I don't really like having two implementations of same code in kernel. There are two ways to deal with it:

Which one do you prefer? I can do both...

Theodore Ts'o replied:

2.6 is allegedly the stable kernel series, so if swsusp is the more stable code base at this point, my vote would be to keep swsusp and remove pmdisk from the kernel. If someone wants to maintain a separate BK-tree that contains pmdisk renamed to swsusp and fix all the bugs, that's great. On the other hand, there are a group of people of are busy doing something very similar with swsusp2, and that effort seems to have a fair number of people working on the patch and testing it.

So if we can somehow go from *three* idependent software suspend implementations implementations to something less than three, and increase the testing and effort devoting to remaining software suspend code bases, this would be a good thing.

Pavel, what do you think of the swsusp2 patch, BTW? My biggest complaint about it is that since it's maintained outside of the kernel, it's constantly behind about 0.75 revisions behind the latest 2.6 release. The feature set of swsusp2, if they can ever get it completely bugfree(tm) is certainly impressive.

Pavel replied, "My biggest problem with swsusp2 is that it is big. Also last time I looked it had some ugly hooks sprinkled all over the kernel. Then there are some features I don't like (graphical screens with progress, escape-to-abort) and ithasvariableslikethis. OTOH it supports highmem and smp." Jan Rychter replied:

It also has the advantage of working extremely reliably on 2.4 (and a large part of the code base is shared, so that's a significant data point). I couldn't get it to crash or do anything bad for months now, and I'm doing at least several suspend/resumes a day on my laptop.

Also, thanks to the excellent compression feature, suspend/resume times are very short and in fact competitive with suspend-to-ram schemes.

I think it's better not to mix personal preferences (such as the escape-to-abort thing) with technical discussions. On a practical level, swsusp2 is the only implementation which works reliably, does its job very well, and has a responsive maintainer willing to fix problems as they arise.

Elsewhere, Benjamin Herrenschmidt said he also supported getting swsusp2 into the main kernel tree. He said:

It may have problems, rough edges, whatever, but keeping out of tree is more or less a guarantee that none of us will look & fix them ;)

If it gets upstream, I'll gladly finish the pmac support for it that I quickly hacked recently for pmdisk as a proof of concept and help figure out some of the remaining problems. I don't feel like doing that with an out-of-tree project.

Pavel asked if Benjamin thought the merge should take place during 2.6, or should wait until 2.7 opened up. Benjamin replied, "2.6. I don't see any problem merging it at this point as long as it's not invasive (I haven't looked at the code though). If it's self-contained, it's more/less like adding a driver." Pavel looked over the code, and found it to be very invasive. He thought it would be hard to get it into 2.6, and even the 2.7 timeframe looked iffy to him now; and folks started discussing ways of taking out some of the most invasive changes, to make the rest more palatable.

4. Linux 2.6.4-mm2 Released

14 Mar 2004 - 23 Mar 2004 (89 posts) Archive Link: "2.6.4-mm2"

Topics: FS: NFS, FS: ReiserFS, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux 2.6.4-mm2, saying:

5. Improvements

14 Mar 2004 - 18 Mar 2004 (7 posts) Archive Link: "BK/Web improvements (includes patch server)"

Topics: Version Control

People: Larry McVoyErik AndersenDavid WoodhouseAndy Isaacson

Larry McVoy said:

I've made a few changes to the BK/Web service on BK/Bits. There are some cosmetic changes but the substantial changes are as follows:

Check it out at and let me know if you find a bug.

Erik Andersen replied:

Hey thats cool, I know I will use this often to slurp down patches of interest.

<obligitory request for yet more stuff which is almost certain to piss you off since you just gave me yet-another-something-for-free>

I'm curious if you might consider adding a diff -Nur style patch vs the last tagged version? I often go to:

to obtain this sortof a patch, for example when I want to submit a patch that is relevant to the current kernel tree, rather than 1000 patches behind. Sadly, these are often rather out of touch with reality. Check out for example the 2.4 one, which has been stuck since March 8th. :-(

Right now I can go to, for example:|tags
and see the list of patches, and thanks to your latest update, I can now click on each patch one-by-one to suck down a diff. I would sure love to be able to obtain the lot as cumulative patch of everything after the last tagged version.

I do not know if that is something you might consider, if doing so suites your business model, if doing so would make unreasonable demands on your donated bandwidth, cpu power, etc, etc, etc. But such a thing would certainly come in handy, if you felt so inclined.

Of course, an alternative solution would be for someone to fix the testing/cset/ scripts to not get wedged...

David Woodhouse remarked, "The 'bk pull' was stuck in recv() and seems to have been that way for days. I've killed it."

Andy Isaacson said that people should send requests to him rather than Larry; and added regarding getting a cumulative patch since the last tagged version:

This is most profitably done outside of bkbits -- the URLs you point to should work (there's no reason they can't be made to go) and it's hard to see the payoff to bkbits to providing it internally.

Gotta remember, bkbits is more than just kernel stuff. We're probably not going to add code that is only useful to the kernel project.

The stuff larry added this weekend, by comparison, is stuff that makes our lives better and has a payoff for us and our customers, while simultaneously making life better for bkbits users. Win-win. (Or is that win-win-win?)

6. Trying To Clarify Software Suspend

15 Mar 2004 - 18 Mar 2004 (14 posts) Archive Link: "Remove pmdisk from kernel"

Topics: Software Suspend

People: Pavel MachekAndrew Morton

Pavel Machek posted a patch to remove pmdisk from the kernel; Andrew Morton asked if pmdisk was still being maintained; and also asked if swsusp2 should be accepted into the kernel. Pavel said he didn't think pmdisk was still being maintained, and he added that swsusp2 had "hooks all over the place" , making it very invasive; but Fedor Karpelevitch suggested that this might be the very reason it worked well for so many people. There was no real resolution during the thread.

7. Status Of fsync()

17 Mar 2004 - 22 Mar 2004 (40 posts) Archive Link: "True fsync() in Linux (on IDE)"

Topics: Disks: IDE

People: Peter ZaitsevJens Axboe

Peter Zaitsev asked:

is there any way in Linux to do proper fsync(), which makes sure data is written to the disk.

Currently on IDE devices one can see, fsync() only flushes data to the drive cache which is not enough for ACID guaranties database server must give.

There is solution just to disable drive write cache, but it seems to slowdown performance way to much.

I would be also happy enough with some global kernel option which would enable drive cache flush on fsync :)

Jens Axboe said, "Chris and I have working real fsync() with the barrier patches. I'll clean it up and post a patch for vanilla 2.6.5-rc today." Peter and others were happy to hear about this.

8. Linux 2.6.5-rc1-mm2 Released

17 Mar 2004 - 19 Mar 2004 (4 posts) Archive Link: "2.6.5-rc1-mm2"

Topics: Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux 2.6.5-rc1-mm2, saying:

9. libata Update Against 2.6

18 Mar 2004 - 19 Mar 2004 (4 posts) Archive Link: "[PATCH,RFT] latest libata (includes Silicon Image work)"

Topics: BSD: FreeBSD, Serial ATA

People: Jeff Garzik

Jeff Garzik said:

Attached is the latest libata patch against 2.6.x mainline. Although not 100% of content, most of this patch resolves around getting Silicon Image into better shape. As I mentioned in my last post, this patch affects all libata users, so plenty of testing is requested.

Silicon Image-related changes:

10. Linux 2.6.5-rc2 Released

19 Mar 2004 - 24 Mar 2004 (14 posts) Archive Link: "Linux 2.6.5-rc2"

Topics: Hot-Plugging, Kernel Release Announcement, Sound: ALSA, USB

People: Linus Torvalds

Linus Torvalds announced 2.6.5-rc2, saying that it contained patches for "Hotplug CPU's, USB, ALSA, input layer updates. And various random things."

11. Linux 2.4.26-pre5 Released

19 Mar 2004 - 21 Mar 2004 (4 posts) Archive Link: "Linux 2.4.26-pre5"

Topics: Disks: SCSI, Power Management: ACPI, USB

People: Marcelo TosattiBert KammererDoug Ledford

Marcelo Tosatti said:

Here goes the fifth -pre of 2.4.26.

It includes a number of USB bugfixes/updates, SCSI driver/stack fixes from Doug Ledford, another ACPI update, amongst others.

This is probably the last -pre of 2.4.26 series.

Bert Kammerer said:

Ever since 2.4.25, when compiling it in to any RedHat 7.3 machine, the following appears in dmesg:

attempt to access beyond end of device
03:02: rw=0, want=1020128, limit=1020127

I traced this to the mount version that ships with RedHat 7.3 (mount-2.11n). Upgrading mount to a newer version gets rid of the messages, but I am unsure as to whether or not the errors are really going away. Do you have any comments/suggestions concerning this issue?

Marcelo replied, "This error is harmless: Dont worry. It will be fixed in -rc1 (which should be out Monday or so)." Bert thanked him, and the thread ended.

12. Linux 2.6.5-rc2-mm1 Released

21 Mar 2004 - 23 Mar 2004 (6 posts) Archive Link: "2.6.5-rc2-mm1"

Topics: FS: ext2, FS: ext3, Kernel Release Announcement

People: Andrew MortonDave Jones

Andrew Morton announced Linux 2.6.5-rc2-mm1, saying:

13. Status Of OSS

22 Mar 2004 - 24 Mar 2004 (21 posts) Archive Link: "OSS: cleanup or throw away"

Topics: Sound: ALSA, Sound: OSS

People: Jos HulzinkAdrian BunkDiego Calleja GarciaBill DavidsenDiego Calleja

Jos Hulzink said, "While fixing some "deprecated" issues in the OSS drivers, I wondered whether this makes sense, as entire OSS is marked deprecated. Will OSS make it until 2.7, or will it be dropped soon ? (In other words, should I take care of the OSS drivers or not bother about them)" Adrian Bunk replied:

OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most likely be removed in 2.7.

I wouldn't spend time to fix deprecated warnings in OSS code, such cleanups are wasted time for code that will most likely be removed in 2.7.

Diego Calleja Garcia replied, "Personally, as an user, I'd like to have the OSS drivers which don't have a ALSA equivalent for my old hardware. There're several sound cards with both ALSA and OSS drivers where ALSA works much better 99% of the time. Those could be safely removed (even in the 2.6 timeframe, I'd argue) but I'd like to keep the ones without an alsa equivalent for my old hardware (specially now that we have a -tiny tree ;) however I can understand that if they don't have a maintainer they'll get removed..." Bill Davidsen replied:

The real issue with removing OSS from a stable kernel is that a kernel update should not break existing system software (at least compliant software). As of early 2.6 it seemed that you had to update to the ALSA mixer and {something I don't remember} if you used the OSS emulation. I just used OSS and it worked. Based on only two systems, so it may not apply.

Stable and install new sound software don't seem to mix well. I suggest that the current course is a good one, keep both systems in the stable kernel.

14. Setting A Non-Executable Stack For ELF Binaries

23 Mar 2004 - 24 Mar 2004 (28 posts) Archive Link: "Non-Exec stack patches"

Topics: Executable File Format

People: Kurt GarloffAndrew MortonIngo Molnar

Kurt Garloff said:

find attached a patch to parse the elf binaries for a PT_GNU_STACK section to set the stack non-executable if possible. Most parts have been shamelessly stolen from Ingo Molnar's more ambitious stackshield

The toolchain has meainwhile support for marking the binaries with a PT_GNU_STACK section with ot without x bit as needed.

If no such section is found, we leave the stack to whatever the arch defaults to. If there is one, we explicitly disabled the VM_EXEC bit if no x bit is found, otherwise explicitly enable.

I believe this part should be merged into official mainstream kernels. Ingo, what do you think?

Ingo Molnar liked the patch, and Andrew Morton said:

This patch propagates the PT_GNU_STACK setting into the vma flags, allowing the architecture to set the stack permissions non-executable if the architecture chooses to do that, yes?

Which architectures are currently making their pre-page execute permissions depend upon VM_EXEC? Would additional arch patches be needed for this?

This may not get past Linus of course. It doesn't even get past me with that magical undocumented -1/0/+1 value of the executable_stack argument. Please replace that with a proper, commented, #defined-or-enumerated value, thanks.

Kurt updated the patch, and the discussion skewed off and petered out.

15. Linux 2.2.27-pre1 Released

24 Mar 2004 (1 post) Archive Link: "Linux 2.2.27-pre1 released"

People: Marc-Christian Petersen

Marc-Christian Petersen announced, "now some more fixes with 2.2.27-pre1. Please test. Have fun :)"







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.