Kernel Traffic #221 For 30 Jun 2003

I wouldn't have a problem with this, except that you've been deferring the ACPI merge for over a year. We've been maintaining this patch outside the mainline tree for EIGHTEEN MONTHS. Please stop leading me along. Will you EVER merge it?

I am confident it will merge cleanly.
I am confident it will cause no problems when CONFIG_ACPI=off.
I am confident the total number of working machines will go up.
I am willing to bet $500 of MY OWN MONEY on this.

Talk to me, man. What would make you happy? A lot is riding on this.

Its been in 2.4.21-ac for a while. I have exactly zero reports of it causing problems in the acpi=n case, and a whole raft of "the first Linux that runs on my toshiba/compaq/hp laptop"

Works well enough for me to have faith in it now.

My plan for 2.4.22 is:

• Include the new aic7xxx driver.
• Include ACPI. (I now realized its importance). Already discussing with Andrew the best way to do it.
• Fix the latency/interactivity problems (Chris, Nick and Andrea working on that)
• Merge obviously correct -aa VM patches.

Those are the most important things that are needed now, I think.

I think I'll call this kernel the "sticky turtle", in honor of that historic "greased weasel" kernel, and as a comment on how sadly dependent I've become on the daily BK snapshots. It's been too long since 2.5.70.

I'll do better, I promise. While most developers happily use either the daily snapshots or the BK tree itself, not everybody does, and a lot of users want "real releases".

There's nothing hugely interesting here, but Al Viro ha sbeen cleaning up the tty layer, and Stephen Hemminger has been fixing up some network device alloc/free issues with the help of various people.

And obviously there are the normal usb/pcmcia/sound/architecture updates. With driver models and networking thrown in as a bonus.

Ok, I waited too long for 2.5.71, so here's a more timely 2.5.72 release.

It's extra timely largely because the hash list poisoning found some problems in the RPC code, making NFS break. Trond found and fixed the breakage, so 2.5.72 should work fine in an NFS environment too. Let's see if the list poisoning shows any other dodgy list users. Knock wood.

Also, Arnaldo has cleaned up a lot of the networking code to use the generic hash lists, instead of the old ad-hoc net-specific list walking code. That code has been tested pretty well, but please holler if you see something.

Changelog for other details appended.

The other big news - well, for me personally, anyway - is that I've decided to take a leave-of-absense after 6+ years at Transmeta to actually work full-time on the kernel.

Transmeta has always been very good at letting me spend even an inordinate amount of time on Linux, but as a result I've been feeling a little guilty at just how little "real work" I got done lately. To fix that, I'll instead be working at OSDL, finally actually doing Linux as my main job.

[ I do not expect a huge amount of change as a result, testament to just /how/ freely Transmeta has let me do Linux work. My email address will change to "torvalds@osdl.org" effective July 1st, but everybody is trying to make the transfer as smooth as possible, so we'll make sure that there will be sufficient address overlap etc to not cause any problems ]

OSDL and Transmeta will have a joint official (read: "boring". You should have seen the bio - that didn't make it - that I suggested for myself for it ;) press-release about this tomorrow morning, but I just wanted to say thanks to Transmeta. It has been a special place to work for, and hello to OSDL that I hope will be the same.

Snif. I'm actually all teary-eyed.

The attached patch adds automounting support and mountpount expiry support to the VFS.

This patch involves the adding the following features:

1. A new dentry operation that (a) marks a dentry as being an automount point, and (b) gets called by the VFS to come up with a vfsmount structure which the VFS then stitches into the mount tree fabric at the appropriate place.
2. A new lookup flag that is used by sys_*stat() to prevent automounting of the path endpoint. This means "ls -l" in an automounter directory doesn't cause a mount storm, but will display all the mountpoints in that directory as subdirectories (either the underlying mountpoint dir or the root dir of the mounted fs if the mountpoint has been triggered already).
3. do_kern_mount() is now exported.
4. The vfsmount structure has acquired, amongst other things, a timeout field. If mntput() notices a vfsmount reach a usage count of 1, then the vfsmount expiry time is set and the namespace that contains the vfsmount has its expiration work chitty queued.
5. The namespace structure has acquired a work struct that is used to actually perform vfsmount expiry under process context.

I'm not too happy with it. If nothing else, IMO it's the wrong way to solve the problem - if you want a bunch of filesystems look like a single object (i.e. go together wherever we mount it, etc.), make it a filesystem. That would make a lot of sense, and not only for AFS.

We need a light-weight automount. No arguments here. But it should be per-namespace - i.e. "I want to have <foo> mounted on /usr/barf on demand and I have no intention to screw somebody else - somebody who might have the same directory seen as /usr/local/debian/barf and want <blah> mounted on demand there".

Namespace is controled by owner of that namespace. It is a security boundary, among other things. And events in one namespace should not cause mounts in another. Yes, AFS wants an illusion of single filesystem composed in fixed way from many pieces. But if you want to do that, do it right - make sure that it acts as a single chunk in mount tree. IOW, make it look like a single filesystem.

I've revised my patch to make sure a process in one namespace doesn't change the topology of another namespace (kern_automount() will return an error in that case, as does (u)mount). As a bonus, check_mnt() has been simplified to take account of the namespace pointer now in vfsmount.

I've also fixes it so that if an automounted subtree is touched with "mount --bind" or "mount --move", then the base of that tree has its expiry timeout cleared, thus making it a permanent fixture (until manually unmounted).

You _still_ don't get it. OK, the last time: kern_automount() will always do the same thing, no matter which namespace we are it. It might be OK for AFS, but it's definitely unfit for any other use.

No amount of "use of (u)mount to rearrange topology" will help here - with your code you have dentry marked, and stepping on it (in any namespace, in any instance of that fs in a namespace) will always do the same thing. And that is Wrong(tm).

Okay, it turns out I don't really need a special operation to deal with automount points... as HPA was pointing out, the same can be done by giving a directory a follow_link() operation...

However, would you consent to accept this patch (or something similar)? It has the actual automounting stuff stuff taken out, leaving two parts:

1. A convenience function (__do_add_mount) that a module can call to insert a vfsmount into the mount topology at a point described by a struct nameidata (as would be passed to follow_link).

   This can be taken out if you insist on my bouncing the mount parameters down to userspace so that it can issue a mount - provided something approximating fmount() is also provided so that inter-namespace mounting can be done under controlled circumstances.

2. Automatic mount point expiry. This allows any mountpoint to be given a timeout, such that when mntput() detects that the vfsmount is only used by its parent, a work chitty will be enqueued to cause the containing namespace to be vacuumed later for dead mounts.

I'd also like to make it so that any mount can be given a "timeout" argument, but I'm not sure what the best way to do so is.

A patch set for kexec for 2.5.72 is now available. This patch set is based upon the stable 2.5.{67,68,69,70,71} versions.

This patch was tested to work (not counting a VESA framebuffer initialization problem after kexec-ing a new kernel) on a dual-proc P4-1.7GHz Xeon system.

More info here:
http://www.osdl.org/archive/andyp/bloom/Code/Linux/Kexec/index.html

Unified full kexec patch for 2.5.72 is here:
http://www.osdl.org/archive/andyp/kexec/2.5.72/kexec2-2.5.72-full.patch

Not that anyone cares, but a unified full patch for 2.5.71 is here:
http://www.osdl.org/archive/andyp/kexec/2.5.71/kexec2-2.5.71-full.patch

Unstable 2.5.69 kexec patches from Eric Biederman are available here:
http://www.xmission.com/~ebiederm/files/kexec/

A patch for kexec in 2.5.72-mm1 is now available. This patch is based upon the stable 2.5.72 version.

This patch has been lightly tested to work on a dual-proc P4-1.7GHz Xeon system. If you try it, and you use the VESA framebuffer, expect darkness on your screen during the reboot. ;^)

More info here:
http://www.osdl.org/archive/andyp/bloom/Code/Linux/Kexec/index.html

The patch:
http://www.osdl.org/archive/andyp/kexec/2.5.72-mm1/kexec2-2.5.72-mm1-full.patch

Source for the matching user-mode tool:
http://www.osdl.org/archive/andyp/kexec/2.5.72-mm1/kexec-tools-1.8-2.5.72-mm1.tgz

A patch set for kexec for 2.5.73 is now available. This patch set is based upon the stable 2.5.{67,68,69,70,71,72} versions.

This patch was tested to work on a dual P4-1.7GHz Xeon system, a uniprocessor P3-800 system, and a dual P3-866 system. I continue to observe strangeness with the re-initialization of the VESA framebuffer (character-based console TTY worked correctly), a kernel oops in the 2.5.72 version on a 4-way while preparing the reboot memory buffer, and a hang seen when using the serial console (RS232).

More info here:
http://www.osdl.org/archive/andyp/bloom/Code/Linux/Kexec/index.html

Unified full kexec patch for 2.5.73 is here:
http://www.osdl.org/archive/andyp/kexec/2.5.73/kexec2-2.5.73-full.patch

Source tarball of the matching user-mode utility for kexec 2.5.73:
http://www.osdl.org/archive/andyp/kexec/2.5.73/kexec-tools-1.8-2.5.73.tgz

Unstable 2.5.69 kexec patches from Eric Biederman are available here:
http://www.xmission.com/~ebiederm/files/kexec/

I don't go out to fetch patches, I really want to see them come to me (and even then preferably through a few people acting as quality control and maintainership).

And if there is no clear maintainership relationship and you need to send them directly to me, I really want plain-text patches (they can be big if needed), with:

• one patch per email. Not attachements, and not several patches in one email one after the other. Several emails, with one patch each, and if they are interdependent, make the subject line be something like

          [DVB PATCH 1/9] Replace frobutomic counter with sequence numbers

  so that when they get re-ordered by the email system (as they inevitably will be), I can see it from the overview.

  The "[xxx]" syntax is important: my scripts will automatically strip that part out and replace it with "PATCH", leaving the commit message as just

          [PATCH] Replace frobutomic counter with sequence numbers

  since once it's in the tree, the ordering is implicit in the SC.

• explanation of the patch for the changelogs at the top of the patch, so that I don't have to make up my own explanations for what it does and get it wrong.
• Make sure your mailer doesn't corrupt the message with whitespace damage (spaces at ends of lines should remain, and tabs should be tabs), or with stupidities like 7-bit quoted-printable crap.

Please.

1.18 series of the driver has been upgraded to 1.18i. This driver has fixes for management applications not working with stock 1.18f driver. Other changes are: Kernel would panic if 2.00.x megaraid driver is loaded on top of 1.18h or previous drivers. This was because of a bug in older drivers which were not reserving the controller's memory region.

This driver also incorporates the important changes made 1.18g and 1.18h driver for firmware handshake. The driver and the patch for 1.18f driver can be downloaded at:

ftp://ftp.lsil.com/pub/linux-megaraid/drivers/

I have had some luck resolving the GPL violation by wireless manufacturers issue. I have sent letters regarding the issue to Linksys, Belkin and Buffalo. This is the letter I received from Buffalo Technologies and below that is the letter I sent to the three manufacturers:

Hi Sir,

We are aware of these requirements and we have the PDF document (attached) and a statement/notice that will be put onto the website within 48 hours for this product. Please let me know if you require further assistance or if you would like to talk further.

NOTICE:
This product uses software of GPL/LGPL.
You have the right to acquire source code, change it, and re- distribute it.
The warranty on the product is only applicable if the original or an official Buffalo firmware is on the unit.
Please refer to GNU_LICENSE.PDF.
We don?t have any obligation to pay if a user has to pay to distribute or change the source code.

Thanks for your time.

Craig Reid
Technical Sales Engineer

-----------

Dear sirs,

Hereby I would like to inform you that the software on at least one of your products is offered in violation of the General Public License (GPL) as published by the GNU Software Foundation. This may not be known to you due to inclusion of acquired or licensed technology from third-party manufacturers in your product.

The affected product is the Buffalo (Melco) WBR-G54 Wireless Access Point

The infringement of the GPL consists of the following:

Your product makes use of Linux kernel version 2.4.5 and Busybox software, which are both licensed under GPL terms and conditions. The GPL allows copying and distribution of licensed software, provided that the complete corresponding machine-readable source code or a written offer to a complete machine-readable copy of the corresponding source code accompanies the product. As you have fulfilled neither of these obligations, you are in violation GPL terms and conditions.

Your product includes a kernel driver module that is inserted into the GPL licensed Linux kernel when the product is turned on. There is no possible way for the user to prevent the insertion of this module into the kernel. It is also impossible for the user to remove the kernel module from the running kernel. The operation of the included software on your product depends on the operation of the kernel module. For these reasons the kernel driver module is not offered as a separate work as described in Section II of the GPL and must therefore be distributed under the terms and conditions of the GPL. As you have not included the complete corresponding machine- readable source code or a written offer to a complete machine- readable copy of the corresponding source code you are clearly in violation of GPL terms and conditions.

Because of the huge liability your company could be facing I advise you to take appropriate measures to cease offering your product in violation of the GPL.

With Regards,

Richard Ten Brink