Kernel Traffic #74 For 3�Jul�2000

By Zack Brown

Table Of Contents

Introduction

Robert McMillan wrote to me, "Kernel Traffic was selected as one of the Top 100 Linux Web sites in the June issue of Linux Magazine." [...] " Linux Magazine will be publishing its list of Top 100 Linux Web sites on www.linux-mag.com (http://www.linux-mag.com) at the end of the summer." Yay!

Linux Magazine (http://www.linux-mag.com)

Mailing List Stats For This Week

We looked at 1318 posts in 5257K.

There were 457 different contributors. 209 posted more than once. 182 posted last week too.

The top posters of the week were:

1. Latest List Of Things To Do Before 2.4 Can Come Out

25�May�2000�-�22�Jun�2000 (26 posts) Subject: "LINUX Jobs for 2.4 update"

Topics: Compression, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: FAT, FS: NFS, FS: NTFS, FS: UMSDOS, FS: devfs, I2O, Networking, PCI, Power Management: ACPI, Real-Time, SMP, Samba, Security, USB, Virtual Memory, VisWS

People: Alan Cox,�Tony Hoyle,�Stephen Rothwell,�Jens Axboe,�Rogier Wolff,�Mike Galbraith,�Steve Dodd

Alan Cox posted his latest To Do list for things to do before 2.4 could come out:

  1. Capable Of Corrupting Your FS
    1. E820 memory setup causes crashes/corruption on some laptops
    2. Use PCI DMA by default in IDE is unsafe on VIA VPx x<3
  2. Security
    1. Fix module remove race bug (mostly done - Al Viro)
    2. exec loader permissions
    3. Semaphore races (fix in 2.2)
    4. Semaphore memory leak (fix in 2.2)
    5. Exploitable leak in file locking (Willy)
    6. TTY and N_HDLC layer called poll_wait twice per fd and corrupt memory
    7. ATM layer calls poll_wait twice per fd and corrupts memory
    8. Random calls poll_wait twice per fd and corrupts memory
    9. PCI sound calls poll_wait twice per fd and corrupts memory
    10. sbus audio calls poll_wait twice per fd and corrupts memory
    11. access_process_mm oops/lockup if task->mm changes (Manfred) [user can cause deliberately]
    12. RtSig limit handling bug
    13. Signals leak kernel memory (security) [FIX in ac tree]
  3. Boot Time Failures
    1. IDE fails on some VIA boards (eg the i-opener)
    2. AHA29xx driver appears to stomp other cards
    3. Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC Versa LX with PIIX tuning)
    4. HT6560/UMC8672 ide sets up stuff too early (before region stuff can be done)
    5. Crashes on boot on some Compaqs ? (may be fixed)
    6. IBM MCA driver breaks on Device_Inquiry at boot
    7. DEFXX driver appears broken
    8. ACPI hangs on boot for some systems
  4. In Progress
    1. Dcache threading (Al Viro)
    2. Merge the network fixes (DaveM)
    3. Finish I2O merge (Intel/Alan)
    4. Fix all remaining PCI code to use new resources and enable_Device (mostly done)
  5. Fix Exists But Isnt Merged
    1. Update SGI VisWS to new-style IRQ handling (Ingo)
    2. 64bit lockf support
    3. Support MP table above 1Gig (Ingo)
    4. Finish sorting out VM balancing (Rik Van Riel, Juan Quintela et al)
    5. Dont panic on boot when meeting HP boxes with wacked APIC table numbering (AC)
    6. Scheduler bugs in RT (Dimitris)
    7. Fix eth= command line
    8. HFS is still broken
    9. AIC7xxx doesnt work non PCI ? (Doug says OK, new version due anyway)
    10. 8139 + bridging fails
    11. Fix hpfs_unlink (Al Viro)
    12. put_user is broken for i386 machines (security) - sem stuff may be wrong too
    13. BusLogic crashes when you cat /proc/scsi/BusLogic/0 (Robert de Vries)
    14. Loopback fs hangs
  6. To Do
    1. SHM code corrupts memory
    2. Floppy driver broken by VFS changes. Other drivers may be too (Stuff gets called after _close now - unload race possibly too)
    3. Tulip hang on rmmod/crashes sometimes
    4. Devfs races, Sockfs (removing NULL ->i_sb stuf) (Al Viro)
    5. Restore O_SYNC functionality
    6. Debian report that the gcc 2.95 possibly miscompiles fault.c or mm/remap.c (Perl script available from Arjan)
    7. Fix further NFS races (Al Viro)
    8. Trace numerous random crashes in the inode cache
    9. Test other file systems on write
    10. The netdev name changing stuff broke GRE
    11. Audit all char and block drivers to ensure they are safe with the 2.3 locking - a lot of them are not especially on the open() path.
    12. Stick lock_kernel() calls around driver with issues to hard to fix nicely for 2.4 itself
    13. PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)
    14. pci_socket crash on unload
    15. truncate_inode_pages does unsafe page cache operations
    16. Linux sends a 1K buffer with SCSI inquiries. The ANSI-SCSI limit is 255.
    17. Linux uses TEST_UNIT_READY to chck for device presence on a PUN/LUN. The INQUIRY is the only valid test allowed by the spec.
  7. To Do But Non Showstopper
    1. Make syncppp use new ppp code
    2. Finish 64bit vfs merges (lockf64 and friends missing)
    3. NCR5380 isnt smp safe
    4. DMFE is not SMP safe
    5. Go through as 2.4pre kicks in and figure what we should mark obsolete for the final 2.4
    6. Union mount (Al Viro)
    7. Per Process rtsigio limit
    8. Fix SPX socket code
    9. Boot hangs on a range of Dell docking stations (Latitude)
    10. iget abuse in knfsd
    11. Some people report 2.3.x serial problems
    12. USB hangs on APM suspend on some machines
    13. PCMCIA crashes on unloading pci_socket
    14. ISAPnP IRQ handling failing on SB1000 + resource handling bug
    15. TB Multisound driver hasnt been updated for new isa I/O totally.
    16. Fix boards with different TSC per CPU and kill TSC use on them
    17. DVD-RAM is apparently not working for write currently (Rogier Wolff)
  8. Compatibility Errors
    1. Xterm broke in 2.3.99pre6 (FIONREAD/select loop)
  9. Probably Post 2.4
    1. per super block write_super needs an async flag
    2. addres_space needs a VM pressure/flush callback (Ingo)
    3. per file_op rw_kiovec
  10. Drivers In 2.2 not 2.4
  11. To Check
    1. Check O_APPEND atomicity bug fixing is complete
    2. Protection on isize (sct) [Al Viro mostly done]
    3. Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing for 2.3.x as well
    4. Network block device seems broken by block device changes
    5. Fbcon races
    6. VFS?VM - mmap/write deadlock (demo code seems to show lock is there)
    7. rw sempahores on page faults (mmap_sem)
    8. kiobuf seperate lock functions/bounce/page_address fixes
    9. Fix routing by fwmark
    10. Some FB drivers check the A000 area and find it busy then bomb out
    11. rw semaphores on inodes to fix read/truncate races ? [Probably fixed]
    12. Not all device drivers are safe now the write inode lock isnt taken on write
    13. File locking needs checking for races
    14. Multiwrite IDE breaks on a disk error [minor issue at best]
    15. ACPI/APM suspend issue - IDE related stuff ?
    16. NFS bugs are fixed
    17. Floppy last block cache flush error
    18. Chase reports of SMB not working
    19. Locking on getcwd
    20. floppy fails on some machines
    21. IRDA calls get random bytes before random is set up
    22. Some AWE cards are not being found by ISAPnP ??
    23. SHM segments not always being detached and destroyed right ?
  12. Fixed
    1. Incredibly slow loopback tcp bug (believed fixed about 2.3.48)
    2. COMX series WAN now merged
    3. VM needs rebalancing or we have a bad leak
    4. SHM works chroot
    5. SHM back compatibility
    6. Intel i960 problems with I2O
    7. Symbol clashes and other mess from _three_ copies of zlib!
    8. PCI buffer overruns
    9. Shared memory changes change the API breaking applications (eg gimp)
    10. Finish softnet driver port over and cleanups
    11. via rhine oopses under load ?
    12. SCSI generic driver crashes controllers (need to pass PCI_DIR_UNKNOWN..)
    13. UMSDOS fixups resync (not quite done)
    14. Make NTFS sort of work
    15. Any user can crash FAT fs code with ftruncate
    16. AFFS fixups
    17. Directory race fix for UFS
    18. Security holes in execve()
    19. Lan Media WAN update for 2.3
    20. Get the Emu10K merged
    21. Paride seems to need fixes for the block changes yet
    22. Kernel corrupts fs and gs in some situations (Ulrich has demo code)
    23. 1.07 AMI MegaRAID
    24. Merge 2.2.15 changes (Alan)
    25. Get RAID 0.90 in (Ingo)
    26. S/390 Merge
    27. NFS DoS fix (security)
    28. Merge the RIO driver
    29. Fix Space.c duplicate string/write to constants
    30. Elevator and block handling queue change errors are all sorted
    31. Make sure all drivers return 1 from their __setup functions (Done ?)
    32. Enhanced disk statistics
    33. Complete vfsmount merge (Al Viro)
    34. Merge removed-buf-open directory stuff into VFS (Al Viro)
    35. Problems with ip autoconfig according to Zaitcev
    36. NFS causes dup kmem_create on reload (Trond)
    37. vmalloc(GFP_DMA) is needed for DMA drivers (Ingo)
    38. TLB flush should use highest priority (Ingo)
    39. SMP affinity code creates multiple dirs with the same name (Ingo)
    40. Set SMP affinity mask to actual cpu online mask (needed for some boards) (Ingo)
    41. heavy swapping corrupts ptes (believed so)
    42. pci_set_master forces a 64 latency on low latency setting devices.Some boards require all cards have latency <= 32
    43. msync fails on NFS (probably fixed anyway)
    44. Find out what has ruined disk I/O throughput. (mostly)
    45. PIII FXSAVE/FXRESTORE support

Tony Hoyle suggested adding 2 items to section 7 (To Do But Non Showstopper):

To Tony's first item, Stephen Rothwell posted a patch and explained to Alan, "This is realtive to the patch I just sent you and should fix the problems with powering down SMP boxes using APM."

Elsewhere, Steve Dodd asked if item 5.14 (Loopback fs hangs) referred to the "disable plugin" fix that had been discussed earlier. Alan replied that yes it was, and added, "Its not merged because nobody has yet explained precisely why it works and if its the right solution." Steve offered a technical explanation, and there was some technical discussion involving him, Jens Axboe, Mike Galbraith, Andrea Arcangel, and Gisle Selensminde. Alan had no more to say.

2. Getting Rid Of zImage

13�Jun�2000�-�22�Jun�2000 (66 posts) Subject: "It's time to get rid of zImage"

People: H. Peter Anvin,�Edward S. Marshall,�Tigran Aivazian,�Alan Cox,�Brandon S. Allbery,�Jens Axboe,�Johan Kullstam,�Chris Noe

H. Peter Anvin said it was time to get rid of zImage. He'd pointed it out many times before, but now he really wanted to emphasize that this was the thing to do. He explained:

when Linux was originally created, DOS memory was considered a critical resource and very few computer manufacturers would have ever considered burning this resource for anything that wasn't absolutely critical. This isn't the case anymore, and we're seeing an increasing number of BIOS extensions -- some of them hacks, some of them very necessary -- considering this available space.

With zImage, it is very hard to put the ceiling of the boot loader any lower than approximately 0x9c000. This isn't good enough when a bunch of these extensions are present.

With bzImage, combined with making the setup code segment-relocatable (which shouldn't be too hard), we should be able to boot with much less DOS memory available in the system. However, this requires bootloader restructuring which would make it very hard to retain support for zImage kernels.

Given this, he asked, did anyone see a need to support zImage anymore?

There were a lot of replies, and several sizeable subthreads. Brandon S. Allbery pointed out the perennial problem: traditionally, some systems could boot zImage but not bzImage. He asked if this had been solved. H. Peter replied that as far as he knew, all systems could currently boot bzImage. Any exceptions, he said, should be found and fixed. Elsewhere, Edward S. Marshall reported:

I am typing this on just such a machine. This is preventing my upgrading to 2.4.x, since I can't get a kernel built which fits as a zImage supporting the hardware in the machine plus the features I need (yes, everything that can be is a module), so I'm VERY interested in getting this solved now (previously, it was really just an annoyance). When booting from LILO, I get the following message when specifying a bzImage kernel:

Block move error 0x02

Booting the exact same kernel configuration (the current round of testing is being done with 2.2.16, but it's the same error I've gotten since bzImage was first introduced) as it's zImage counterpart works just fine.

I'm willing to run pretty much whatever tests people are interested in seeing, and can provide system specs for the machine (some of which I've attached below my signature). Current constraints are that the machine is purely Linux, so any tests involving other architectures will be...difficult. ;-)

Let me know what you need.

H. Peter felt this was probably a BIOS problem, and suggested Edward either use the 'syslinux' boot loader, which would bypass the BIOS block-move feature; or trying a very stripped down bzImage, since he was just interested in whether it would boot, not whether it was ideal (he also misspoke, in this post and others, interchanging "bzImage" with "zImage", making it difficult at times to figure out what was being said. Thanks go to Juan Quintela and Jens Axboe for clearing up the confusing areas). Edward did some tests replied that H. Peter seemed to be right: it looked like 'lilo' was having problems with the BIOS. Using the GRUB bootloader he'd managed to boot bzImage kernels.

Elsewhere, Alan Cox said that getting rid of zImage was really something for 2.5; H. Peter suggested, "I would like to suggest making zImage officially deprecated (preferrably including some echo statement in the Makefile), but not removed, in 2.4, and then nuked completely in 2.5." Chris Noe and Johan Kullstam were fine with this, but Tigran Aivazian objected mildly, "well, I don't strictly *need* zImage, but, when you are explaining to someone how Linux kernel boots on x86 it is so much easier to follow all the details in the case of zImage than bzImage. But, I agree, it is purely academical thing - I treat all Linux kernels as something one should print out and hang on the wall :)"

3. Old BIOSes Booting With IDE Disks Larger Than 33.8G

17�Jun�2000�-�20�Jun�2000 (10 posts) Subject: "big disks and old BIOS"

Topics: Disks: IDE

People: Andries Brouwer,�Werner Almesberger,�Shane Wegner

Andries Brouwer reported that under some old BIOSes, an IDE disk larger than 33.8G would cause the BIOS to hang at boot time. Placing a jumper to make the disk appear the proper size would allow the machine to boot, but access to sector 66055248 and above would give I/O errors. However, he continued:

Thanks to the report by Shane Wegner we now have confirmation that in such a case a small Linux utility that executes the READ NATIVE MAX ADDRESS and SET MAX ADDRESS commands suffices to get full capacity back. See also

Jumpers that clip total capacity (http://www.win.tue.nl/~aeb/linux/Large-Disk-11.html#ss11.3)

So, no need anymore to upgrade the BIOS or install MaxBlast. An all-Linux solution suffices.

Werner Almesberger reported that his GA-686LX board with an ancient AWARD BIOS and a Maxtor 93652U8 (~36 GB) was immune to this solution, and that in fact the Maxtor utility wouldn't even recognize the jumper. Andries couldn't believe this, and after a bit of a staircase the thread petered out.

4. 'kswapd' Still No Solution

17�Jun�2000�-�23�Jun�2000 (9 posts) Subject: "kswapd infinite loop"

Topics: SMP

People: Goswin Brederlow,�Rik van Riel,�Juan J. Quintela

Rui Sousa reported what he took to be an infinite loop in 'kswapd', manifesting as extremely high CPU usage under test1-ac19 on his two-way SMP system. After some discussion, Juan J. Quintela said he thought his latest patch solved several infinite loops in 'kswapd'. He gave a link (after some typo correction) to a patch (http://carpanta.dc.fi.udc.es/~quintela/kernel/2.4.0-test1-ac22-riel/kswapd_03.patch) against ac22-riel. Goswin Brederlow tried this and found it to be "less worse, about like the other acXX or plain kernels." Above that in the same email, he'd said, "I tried ac22-riel today. its worse than ever," and Rik van Riel replied quietly, "God I love detailed bug reports..."

5. Some Discussion Of Locking

17�Jun�2000�-�26�Jun�2000 (13 posts) Subject: "spin_lock_irq vs. spin_lock_irqsave."

Topics: Samba

People: Russell King,�Manfred Spraul,�Matthew Wilcox,�Daniel Kobras,�Paul Rusty Russell

Daniel Kobras asked when it was OK to not save/restore processor flags. Specifically, he wanted to know how to determine when spin_lock_irqsave() would be needed in his own code, or if spin_lock_irq() would be sufficient. Russell King explained:

Basically, if you can guarantee that at the point when spin_lock_irq() is called, interrupts will always be enabled, then you can use spin_lock_irq() instead of spin_lock_irqsave().

The reason for this is that you know that interrupts were enabled, so when you come out of your critical region, you can just re-enable them with spin_unlock_irq().

And Manfred Spraul added:

And if you know that the interrupts are always disabled you can use

spin_lock(&lock);

spin_lock(&lock) can also be used in your interrupt handler if your device only uses one interrupt: the kernel guarantees that a interrupt handler is never reentered, even if the interrupt handler runs with enabled interrupts.

The _bh variants disable bottom half delivery [softirqs, tasklets and the old bottom halfs such as timers]. Within your bh handler you can use spin_lock() instead of spin_lock_bh().

Elsewhere, Matthew Wilcox gave a pointer to The Fucked Up Sparc (http://www.samba.org/netfilter/unreliable-guides/kernel-locking/sparc.html) in the Unreliable Guide To Locking (http://www.samba.org/netfilter/unreliable-guides/kernel-locking/lklockingguide.html) by Paul Rusty Russell.

6. Alan Recommends Against BitKeeper

17�Jun�2000�-�23�Jun�2000 (16 posts) Subject: "Linux 2.2.17pre4"

Topics: Version Control

People: Steven N. Hirsch,�Alan Cox,�Larry McVoy

Some confusion came up over which patches were producing which errors, and in the course of discussion Steven N. Hirsch remarked, "I _really_ wish that Larry McVoy's BitKeeper was in regular use, so patchsets can be applied/backed-out in a fine-grained manner." Alan Cox replied, "It wouldnt make any odds. Patchsets have complex inter-dependancies. You dont generally want to go playing mix and match." Bitkeeper was first covered by KT in Issue�#19, Section�#9� (11�May�1999:�Bug Tracking And Revision Control For Linux) , then again in Issue�#38, Section�#5� (27�Sep�1999:�Version Control System Flamewar) , and finally made a momentary mention in Issue�#45, Section�#8� (16�Nov�1999:�Historical Digression) .

7. New Attempt At Fixing 'kswapd' But No Luck So Far

18�Jun�2000�-�20�Jun�2000 (8 posts) Subject: "PATCH: Improvements in shrink_mmap and kswapd"

People: Juan J. Quintela

Juan J. Quintela posted a patch, and announced, "this patch makes kswapd use less resources. It should solve the kswapd eats xx% of my CPU problems." No one replied with any success, and there was some criticism of the patch.

8. Makefiles Inefficient Since 2.2.16

18�Jun�2000�-�20�Jun�2000 (7 posts) Subject: "Very touchy eager-to-remake make or kernel makefiles?"

People: Igmar Palsenberg,�Ricky Beam,�Xuan Baldauf,�Russell King

Russell King reported that during compilation, a lot of files seemed to be getting recompiled even though they hadn't changed. Igmar Palsenberg replied that he'd already posted a bug report on that. He added, "The makefile is realy f*cked up since 2.2.16. Try changing 1 c file, do a make and see that make fails after the System.map is created. No errors are shown." Elsewhere, Xuan Baldauf bemoaned the nonexistence of a global Makefile, which he felt would speed up compilation as well as the development process itself. Elsewhere, Mike Frisch also confirmed the problem, and Ricky Beam explained, "Well, there is a reason... there is a weak build avoidance system within the kernel makefile system that tries to check the "flags" used during compilation. If something doesn't get its flags marked, then it will be forced to be rebuilt -- I toyed with fixing this, but it's too much of a mess to be fixed easily. You'd think after 10 years, someone would have learned to write a makefile *sigh*"

9. Maintaining Buildable Ports

19�Jun�2000�-�23�Jun�2000 (17 posts) Subject: "IA64 version of 2.4.0-test1 has compile errors/config errors"

People: Jes Sorensen,�Jeff V. Merkey,�Matthew Wilcox

A similar discussion was covered recently in Issue�#73, Section�#10� (12�Jun�2000:�Developer Philosophy: Quietly Breaking Hardware Ports In Unstable Series) .

Jeff V. Merkey was having trouble building 2.4.0test1 on the IA64. He posted some information, and Jes Sorensen chastized him for posting to linux-kernel instead of the more specific linux-ia64@linuxia64.org list, since as he put it, "There is a much bigger chance that the appropriate people will read it there." Jeff objected, "I understand that the IA64 folks should get the message in the most efficient manner possible, but unless I am mistaken, there's only "one" master Linux tree, and unless the two are planned to diverge, www.kernel.org should be the central repository for IA64, just like any other Linux port, otherwise, we get the current situation -- the build at www.kernel.org is not always current or at the expected level of completeness that the rest of Linux enjoys. It took me over four hours Sunday to locate and download all the patches and fixes from www.ia64linux.org and hp.com to get the build from www.kernel.org to even compile for IA64." Jes replied, "You know what, it's been like that for non x86 ports for years, we try to fold the stable trees into the official tree and keep the architecture specific changes uptodate in the development trees. However things are changing so fast and there is only *one* Linus that you *cannot* in any reasonable way expect to have anything integrated at all times."

In the same post, Jes added, "linux-kernel is already so overloaded with rubbish because a lot of people keep posting tons of totally non kernel related questions here (or say answers to the list which are just a personal thank you and a copy of the entire previous email .... hint hint). Having a dedicated mailing list per architecture to handle architecture specific questions is very useful." Jeff replied, "I agree so long as folks can get a **WORKING** IA64 linux tree from www.kernel.org. This is clearly not the case today. I am concerned that Intel's IA64 effort may get a black eye if everytime folks download an IA64 Linux from www.kernel.org, they discover that they canot build it." Jes said he could not see Jeff's point. Downloading the sources from www.kernel.org and applying a single patch, produced a working kernel. But Jeff replied that although this might be true, the compilation process produced a lot of warnings and errors, and forced the user to manually edit the config file.

Matthew Wilcox observed, "I don't see why ia64 should be treated any differently from mips/arm/m68k/ppc/sparc/... all of which are in the tree and still need separate patches. It's Just The Way It Works." Jeff reiterated that the patches were extremely difficult to apply, but Matthew finished with, "the same is true for almost all other architectures."

Jeff was not satisfied, and eventually the thread petered out.

10. Hunting For The 'kswapd' Problem

19�Jun�2000�-�20�Jun�2000 (20 posts) Subject: "shrink_mmap() change in ac-21"

Topics: Virtual Memory

People: Linus Torvalds,�Rik van Riel,�Zlatko Calusic

Zlatko Calusic noticed that the 2.4.0-test1-ac21 virtual memory system seemed to remove a test-for-wrong-zone in shrink_mmap(), which caused the system to discard many wrong pages before getting to the right one. In the course of discussion, Linus Torvalds said, "The zone test is _definitely_ needed, because without that test we'll deplete zones that have tons of memory and really should not be depleted.." And Rik van Riel remarked, "Indeed, and reinserting the zone goodness test makes the system perform wonderfully again. It was removed shortly in -ac21 for unknown reasons. Removing that test was done by a few people on IRC when we tried to identify if that was the cause of high kswapd cpu use on low-memory machines"

11. Virtual Memory Opponents Work Together

19�Jun�2000�-�22�Jun�2000 (11 posts) Subject: "test1-ac22-classzone performance"

Topics: Virtual Memory

People: Andrea Arcangeli,�Rik van Riel,�H. Peter Anvin

Rik van Riel and Andrea Arcangeli had another staircase (friendly, this time) about the Virtual Memory subsystem. H. Peter Anvin actually started it off with a report of very bad performance on a high memory machine running 2.4.0-test1-ac22 with Andrea's classzone patch compiled in. Andrea posted a patch, but said he thought the slowdown was not classzone-related. Rik felt that some parts of the patch were wrong, and eventually posted some code of his own. Andrea liked these changes, though he felt it wasn't perfect either, and they went back and forth a bit on the technical details.

12. More On VM: 'classzone' Better In Benchmarks

20�Jun�2000�-�21�Jun�2000 (6 posts) Subject: "ac22-class versus ac22-riel, P133-32Mb laptop"

Topics: Virtual Memory

People: Andrea Arcangeli,�Juan J. Quintela,�Cyrille Chepelov,�Rik van Riel,�Mike Galbraith

Cyrille Chepelov tried comparing 2.4.0-test1-ac22 plus Rik van Riel's strict zone patch, against the same kernel with Andrea Arcangeli's classzone patch instead of Rik's. He measured the cache-, swap-, and buffer-usage of both in a real-world situation. His conclusions were that the classzone patch used slightly less resources. However, it also started applications slower than Rik's patch did, and woke apps out of swap slower as well. Cyrille felt the tests to be inconclusive, favoring neither in any strong way.

Mike Galbraith also did some comparisons between those same kernels, except with Juan J. Quintela's latest patches added in. His measurements involved shoving as much stuff through swap as possible, and he found the classzone kernel to be much faster. There was no discussion.

13. Philosophy Of Listing Security Fixes In Changelog

22�Jun�2000 (3 posts) Subject: "List of security fixes in 2.2.x"

People: Florian Weimer,�Alan Cox

Florian Weimer asked if a complete list of 2.2 security fixes existed anywhere. He remarked, "Alan Cox's "release notes" mention most fixes, but they are remarkably terse regarding security fixes. Is this intentional?" Alan Cox replied, "They should list all fixes reasonably accurately. They may well not tell you how to exploit them. That is intentional."

14. Anonymous Poster Claims GPL Violations Are Accepted By Linux Community

23�Jun�2000�-�25�Jun�2000 (11 posts) Subject: "GPL violation is a Linux Community standard"

People: Jes Sorensen,�Alan Cox,�Richard M. Stallman

An anonymous hotmail account identifying itself only as "Mr. Smith", posted to the list, claiming that various Open-Source-savvy people had told him about an unwritten clause of the GPL and LGPL, in which a distribution of binary-only versions of GPLed code can persist for an unspecified amount of time, as long as the distributor claims that it is only an intermediate package. The anonymous poster sited two cases, involving Tripwire Security and Corel Corporation. In the Tripwire case, Mr. Smith pointed out that, as stated in a press release (http://www.tripwire.com/press/pr.cfml?prid=36&) , they announced they would Open Source their Linux product. But he pointed out that the demo, available at the Tripwire download page (http://www.tripwire.com/downloads/) , violated the LGPL: Mr. Smith said that even after an inquiry by Richard Stallman, they did not provide object files for relinking to modified versions of the LGPLed library. Apparently Tripwire then claimed that the product was just an "intermediate package", after which they have seemingly been allowed to continue in violation of the LGPL.

In the case of Corel, Mr. Smith claimed that they had distributed CDs of their Linux distribution, without any offer of source code. When questioned, they apparently replied that the software was an "intermediate package". According to Mr. Smith, neither Corel nor Tripwire gave any indication of how long this intermediate phase would last.

There was no truly summarizable discussion, but some interesting tidbits, sometimes peripheral, did surface.

At one point, Jes Sorensen remarked, "The real question here is actually why someone hiding behind a hotmail account, without including his real name, posts something like this to linux-kernel where it is completely off topic. And of course the much bigger question why some people just have to reply to it? One can only guess it was a troll."

Elsewhere, Alan Cox remarked, "If someone is providing static linked binaries against glibc and not providing the required offer to either provide a dynamic linked one or a .o file (ie an ld -r) of the application and it is on the Red Hat extra applications disk I'd like to know, along with a copy of the correspondance involved."

Elsewhere, Alan also remarked, "Actually folks get sued for not following copyrights. I've been talking to someone recently who plans to solve the KDE gpl/nongpl issue by issuing cease and desist orders to KDE. Vendors also take it seriously. Some of them anyway"

Richard Stallman also posted to the list in reply to Mr. Smith's initial statement. He said:

Nothing in the GPL, whether written or "unwritten", makes any exception for "intermediate" packages. All distribution of all versions must follow the GPL.

However, the GPL is enforced by copyright holders, and they might find it reasonable to forgive a violation if the perpetrator agrees to bring it to an end reasonably quickly. For instance, I saw no point in threatening to sue Tripwire if they were going make their program free in short order and thus comply permanently. If it drags on, that's a different issue.

Regarding the Corel story, Richard replied, "I thought that Corel had abandoned these plans in September. Since then I have heard nothing about it. Would you please give me more details of this activity? What is the name of the product? Can you tell me the names of some FSF-copyrighted programs that are included?" And finally, he concluded, "no company is entitled to decide to pick and choose which parts of the GPL to follow. We will have to take action, once we get details to base action on."

There was also some talk that the whole topic was not relevant for linux-kernel, and eventually Richard replied to the general sentiment:

I can see why people on the linux-kernel list would consider license violations concerning GNU libc, or any program other than Linux, to be off-topic; the right place to report GNU libc license violations is to the FSF, which is the copyright holder of GNU libc.

I will ask my assistant to check the eight packages you mentioned, and we will take the appropriate actions. Thanks for sending the list. If you find any other such violations, you may as well send them directly to me.

Sharon And Joy

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