About a year ago, I became frustrated with the process of trying to merge a bunch of cleanups that I had done to the swsusp (suspend-to-disk) code. The reasons for this were numerous, but largely irrelevant at this point. In an attempt to accelerate things, I forked the code, called it pmdisk, and merged the cleanups. I had intended to merge the two, but circumstance took another turn for the worst, and I was left with absolutely no time to tend to it, leaving the net effect a major detriment to the overall effort.

Forking the code was the wrong thing to do. I apologize to Pavel for slighting him, and the users that are still left with a suspend-to-disk implementation in limbo.

I've managed to shave off a bit of time, and have cut a set of patches that merge the two, applicable against Linus's latest BK tree. No functionality has been lost, and the cumulative benefit should be better than the previous two efforts. The short summary of the patches follow this email. The patches themselves are in seperate emails. I do not have a publically accessible BK tree, but I can work on that if anyone desires it.

In the end, these patches remove pmdisk from the kernel and clean up the swsusp code base. The result is a single code base with greatly improved code, that will hopefully help others underestand it better.

The swsusp code has also been integrated with the rest of the, albeit small, Power Managment core. This removes a bit of code duplication, and simplifies the main entry points a bit. The major benefit of this is that swsusp does not depend on /proc/acpi/sleep or a modified sys_reboot() system call to be present. It can be used by writing to /sys/power/state. The other major plus is that it can leverage the real low-power states of the platform (e.g. the ACPI S4 state), rather than always shutting the machine down.

I've done a minimal amount of testing, as I am literally on my way out the door Ottawa, but I have verified that it works on at least 1 Pentium-M based laptop (a Compaq Evo N620c). I have not had a chance to port the low-level changes to the x86-64 architecture. It's on the remaining TODO list, along with writing a more formal explanation of the technical changes for Documentation/

I'm interested to hear what people have to say about the patches and encourage everyone to give them a try. [Though, considering many people will be in Ottawa over the next week, I expect most feedback to come from there.. ]

I'll just add Pat's BK URL to my list-of-bk-trees-to-add-to-mm-kernels. That brings it up to 25 external trees, believe it or not.

Pat, that means that anything which you commit gets autosucked into -mm, so if there is a different URL which I should be using, please let me know.

I've created a directory to store known pending v2.4 problems, at http://master.kernel.org/~marcelo/pending-2.4-issues/

INDEX says:
This is the list of pending known pending v2.4 problems, each file represents one issue. Yes, this could be improved, but its KISS right now.

And there's currently only one entry, named "loopback-highmem", which describes a (aha!) loopback highmem deadlock which is still unsolved.

Feel free to mail me detailed description of any other pending problems!

I hope this way we can map the pending and/or not-to-be-fixed issues in a central place.

Part of the reason for dropping cryptoloop is to help dm-crypt mature more quickly.

I've had some off-list email on the security of dm-crypt, and it seems that it does need some work. We need to get the security right more than we need to worry about these other issues.

Let's drop the technically inferior of the two (cryptoloop) and concentrate on fixing the other (dm-crypt).

I use cryptoloop and I would be really annoyed if it disappeared in the stable kernel series. Besides, I read in another mail in this thread that dm-crypt will not work with file-based storage (I'm using cryptoloop on a file), and that it is new and potentially buggy.

I'm really surprised that people here argue that dm-crypt doesn't get enough testing so cryptoloop has to go to force people to test dm-crypt with their valuable data. This is all upside-down. First dm-crypt has to be stable, safe and feature-complete, then people can convert their data to dm-crypt and only then can cryptoloop be deleted.

This adds VLAN support to the 3c59x/90x series hardware.

Stefan de Konink ported this code from the 2.4 VLAN patches and tested it extensively. I cleaned up the ifdefs and fixed a problem with bracketing that made older cards fail.

Sigh. This has been floating about for ever. My reluctance stemmed from largely-theoretical-sounding objections from Don Becker which I didn't fully understand at the time and have now forgotten.

Ben, does the patch look complete/correct to you?

Tons of small fixes all around the tree.

There's an optimized assembly AES implementation for x86 (from Brian Gladman), and a number of driver updates, all of which are reasonably minor.

It would be good if people only sent serious stuff for a while, and we can do a real 2.6.8, ok?

We'll see just how quickly somebody steps up to the plate. I spent some time taking the original Gladman source into gas format, and have a really ugly (untested) direct conversion if somebody wants to work on it.

Side note: Jari Ruusu has himself been distributing the code he now objects to as part of his own linux kernel loop-aes patches. From the loop-aes README:

Copyright 2001,2002,2003,2004 by Jari Ruusu.
Redistribution of this file is permitted under the GNU Public License.

But the original x86 assembler code that is part of that loop-aes patch was copyright Dr Brian Gladman, and was NOT originally under the GPL, so it was Jari Ruusu who originally did something very suspect from a copyright angle. Now he claims he never wanted to GPL it, but the fact is, he's been distributing kernel patches with the code for a long time, and claiming it is GPL'd.

So then David and James wanted to include it into the kernel as part of the standard encryption layer, and I said no, since I felt the copyright wasn't clear. So James asked Dr Gladman for permission to dual-license under the GPL, and got it. So I was happy.

Now Jari Ruusu comes along and starts complaining about things.

Jari: mitä helvetin järkeä tuossa on? Selitä.

It's just _so_ much nicer to work with a code-base where none of the authors might complain about being included.

So even if the original license is GPL-compatible, just the fact that Jari doesn't want his work re-licensed means that I don't want his work in the kernel - whether it's a legal issue or not.

Now, I obviously believe that Jari has acted like an ass, since he has used the very same code under the GPL before, but hey, that's his problem.

Jari - please stop distributing your loop-aes patches. If you consider the license to be non-GPL-compatible, then you have no business distributing the thing as kernel patches. Alternatively, just say it's GPL'd. You can't have it both ways.

You're saying that you consider Gladman's original AES license to be GPL-compatible (ie a subset of it)? That's fine - apparently the FSF agrees.

However, that is incompatible with you then complaining when it gets released under the GPL. If the original license was a proper subset of the GPL, then it can _always_ be re-released under the GPL, and you don't have anything to complain about.

So which is it? Either it's GPL-compatible or it isn't. If it is GPL-compatible, why are you making noises? And if it is not, why are you claiming that you can distribute loop-AES as a GPL'd project?

You seem to be very very confused, Jari. There really _are_ only these two cases:

• the AES code is GPL-compatible

  This fundamentally means that it has no more restrictions than the GPL, and that in turn means that it can always be re-licensed as GPL'd code. Which James Morris did (well, it was dual-licensed, but the only license that matters for the _kernel_ is the GPL).

  In this case, you can't say "you can't do that". I'm sorry, but James _can_ do that, and it is _you_ who can't do that.

• the AES code is _not_ GPL compatible.

  This fundamentally means that you can't relicense it under the GPL, but it _also_ means that you can't link it with GPL code, since the GPL _requires_ that the code be under the GPL. In this case, loop-AES was always wrogn and lying about beign GPL'd, and you should stop distributing it immediately.

You can't have it both ways. And there aren't any third alternatives.

Explain yourself.

Copyright law has nothing to do with "licensing". In fact, if you actually read copyright law, you will find that the _only_ thing that it's about is the right to distribute a work and the right to make derived works.

(Side note: there are also certain "right of attribution" etc, but that's still not about re-licensing and those are about the author, not the owner of the copyright).

In other words, being the "owner" of a work has nothing to do with the right to "relicence".

Being able to license somebody else to distribute the work does NOT require ownership. It only requires a _license_ to do so. You can keep owning your copyright, and let somebody else distribute the copy for you by liccensing him to do that.

And a license like the BSD license that allows very broad rights to _everybody_ means that pretty much everybody can not only distribute it, but since the BSD license doesn't even limit how they re-distribute it, you can distribute it with some additional requirements of your own.

Why do you think Microsoft etc can take BSD code and then slap their EULA on it? Right. They were given the right to distribute.

The GPL doesn't say "you can link this with a GPL-compatible license". It says:

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

Notice? It says "this License". Not "this license or some more permissive license".

The ONLY license you can use to create a GPL derivative is the GPL itself.

And the way "GPL-compatible" licenses work is _exactly_ because these licenses are "weaker" than the GPL, and as such can always be _relicensed_ as the GPL.

THAT IS WHAT GPL-COMPATIBLE MEANS!

So when you claim that the code isn't GPL-compatible, and at the same time claim that we can't re-license it under the GPL, you are very very confused indeed. Either it is GPL-compatible, or it is not. And if it is GPL-compatible, that ABSOLUTELY means that it can be relicensed under the GPL.

Comprende?

Anyway, the point is moot. We've removed the code you touched, and I'm about to apply the new version that is based on Gladman's code (I did the conversion myself, and James Morris did the final stuff and the integration with the rest of the code).

And we did that not for legal reasons, but because quite frankly, I don't want to have _anything_ to do with somebody as confused as you are.

I don't have any other choice here than to permit re-licencing the code. My 04-Aug-2004 18:04:46 +0300 posting where I denied re-licencing right was completely wrong. I'm sorry about that.

For loop-AES users I uploaded a patch here that updates licenses to be GPL-compatible: http://loop-aes.sourceforge.net/updates/aes-GPL.diff

Hey, Welcome back, Jari.

It's easy to be wrong. It's much harder to come out and say so.

Let's leave this spat behind us. Friends?

The general changes are:

• added new hardware support
• code cleanup (typedefs, include files, etc.)
• simplified the directory structure (all files were arch/ia64/sn/io/ are now under arch/ia64/sn/ioif/)
• code size reduced by >50%
• major reorg of the code itself
• copyright updates

Yikes, this is truely horrible. First your patch ordering doesn't make any sense, with just the first patch applied the system won't work at all. Please submit a series of _small_ patches going from A to B keeping the code working everywhere inbetween.

Your new directory structure is very bad. Just stick all files into arch/ia64/sn/io/ instead of adding subdirectories for often just a single file.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc3/2.6.8-rc3-mm1/

• Added David Woodhouse's MTD tree to the "external trees" list

• Dropped the staircase scheduler, mainly because the schedstats patch broke it.

  We learned quite a lot from having staircase in there. Now it's time for a new scheduler anyway.

The patch below implements RSS ulimit enforcement for 2.6.8-rc3-mm1. It works in a very simple way: if a process has more resident memory than its RSS limit allows, we pretend it didn't access any of its pages, making it easy for the pageout code to evict the pages.

In addition to this, we don't allow a process that exceeds its RSS limit to have the swapout protection token.

I have tested the patch on my system here and it appears to be working fine.

Hard limiting a process when there is memory available means that it's trying to saturate the IO subsystem, slowing down other tasks in the system.

Basically when memory isn't the bottleneck, I think you shouldn't try to create an IO bottleneck for the other tasks in the system, just because an RLIMIT_RSS got set.

The downside is that the pages of the process need to be swapped out when something else needs the memory, but if the alternative is constant swapping, we'd have the IO overhead regardless...

What I want the feature to do is allow users to set an RSS rlimit to prevent a process from hogging up all the machine's memory.

I am not looking for a hard memory limit, since that would just cause extra IO, which has bad consequences for the rest of the system.

In addition, I would like the patch to be relatively low impact, not giving us much maintenance overhead or much runtime overhead.

If anybody has good reasons for needing hard per-process RSS limits, let us know. So far I haven't seen anybody with a workload that somehow requires a hard limit.

Here goes the last -rc, fixing a couple of typos to the big file offset patch from -rc5.

-final will be out in a couple of hours, now for real.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc3/2.6.8-rc3-mm2/

• Added a little patch to the CPU scheduler which disables its array switching.

  This is purely experimental and will cause high-priority tasks to starve lower-priority tasks indefinitely. It is here to determine whether it is this aspect of the scheduler which caused the staircase scheduler to exhibit improved throughput in some tests on NUMAq.

• If some devices mysteriously stop working, try booting with pci=routeirq. If that fixes it, please send a report, Cc'ing bjorn.helgaas@hp.com. See remove-unconditional-pci-acpi-irq-routing.patch

Hmm.. Not a huge amount of changes, but enough that I wouldn't have felt comfortable releasing it as 2.6.8. I've been hoping to resolve the dcache reports, and we found _one_ bug, but that one would likely not affect a whole lot of people, so..

Some ARM updates, the i586 AES code rewrite, some ppc updates.. A large portion of the patch actually ends up being cleaning up some /proc files (thanks to Al for doing seq-file conversions) and me fixing some broken calling conventions in sysctl and sound /proc handling.

The shortlog gives a reasonable picture of the changes.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc4/2.6.8-rc4-mm1/

• Mainly little fixes. Some recovery from damage due to the recent large influx of patches.
• I am offline for the rest of the week.

The Minneapolis Cluster Summit came and went 10 days ago, with excellent attendance and high-quality interaction all round. Over the last few days I've been collecting slide presentations and related material onto this page:

http://sources.redhat.com/cluster/events/summit2004/presentations.html

Unfortunately, due to manpower limitations and short lead time, we weren't able to arrange for audio recordings, which would have been great since both presentations and discussion were packed full of useful material. I guess this means we have to do it again next year, this time with a tape recorder! As for the results... discussion continues on linux-cluster and other mailing lists, please judge for yourself.

https://www.redhat.com/mailman/listinfo/linux-cluster
http://lists.osdl.org/mailman/listinfo/cgl_discussion
http://lists.osdl.org/mailman/listinfo/dcl_discussion

As author of the current Linux SATA driver, I get the brunt of the questions and "bug reports" about "Linux doesn't support my hardware SATA RAID". Sigh. Silly marketing departments.

Thus, I have created a FAQ. You might sense a theme...

http://linux.yyz.us/sata/

I'm sitting on the vendor's driver for these cards. How does your work differ from this?

hch questioned why we need the driver at all: just put the card in JBOD mode and use s/w raid drivers. But the thing does have an on-board CPU and the idea is that by offloading to that, the data transits the bus just a single time. The developers are off doing some comparative benchmarking at present.

Damn. I think the stupid typo in fs/nfs/file.c from the fcntl f_op removal patch is the problem.

Andrew, since I'm gone in another hour, how about you try to make a 2.6.8.1 with this, since this is clearly a good reason for one?

Somewhere along the 2.6 series, there was a change made that causes distclean to automatically delete the debian/ subdirectory from the top of the kernel tree. This causes grief for the official debian kernel packages; the debian directory shouldn't be deleted in the packages. Please apply the attached patch; it causes the debian/ subdirectory to only be deleted if there's no debian/official.

An even better solution would be to mark the debian directory as being created by the kernel (touch debian/linus), and only delete it if the kernel created it.

Such special cases are not acceptable.

If this causes a problem then there are the following options:

1) Rename directory in debian or the kernel
2) Debian apply a patch to the kernel

Preference to 1).

How about not deleting the directory if you haven't created it? Debian already applies patches to the kernel, but we feed changes/fixes back to linus and co; this is one of those fixes that should be in the main kernel. If you're going to provide a make rule for *Debian*, then make it consistent with Debian packaging standards. Otherwise, why even bother? Debian has its own supported methods for creating kernel packages (named, oddly enough, kernel-package).

Honestly, I'd rather see the deb rule removed completely; Debian and Debian-derived distributions provide their own kernel packages. Users who compile their own kernel have the option of using a Debian supported method for building kernel packages (they can also simply copy images around, without bothering w/ packages). Generating a package without kernel-package is not supported; does it even handle grub and lilo updates in postinst?

Here goes the first 2.4.28 -pre release.

It contains a big SATA update with long list of fixes, a networking update (mainly SCTP fixes), lib crypto fixes and the addition of the Khazad algorithm, add prism54 wireless driver, SPARC64 update, cciss SCSI driver fixes, couple of storage devices added to SCSI device list, agpgart support for i915 chipset, OOM killer rare-case bugfixes, a VM bugfix which could cause deadlocks under OOM conditions, a bunch of warnings fixes, and initial support for gcc 3.4.

I still have a few bugfixes pending on my inbox, which should be merged next week.

Just released a small update to ethtool, version 2, posted at

http://sourceforge.net/projects/gkernel/

Like its cousin "blktool", ethtool now has a simplified version scheme, an ascending number.

For those unfamiliar with ethtool, it is a utility designed to configure specific features founds on most ethernet cards.

Summary of changes (mainly the new version scheme):

• Feature: ethtool register dump raw mode
• Feature: return results of self-test back to OS via exit(2)
• Feature: add verbose register dump for pcnet32, fec_8xx
• Maintenance: update to more recent autoconf
• Maintenance: minor updates to e1000-specific module
• Bug fix: Remove silly restriction on ethernet interface naming