[LWN Logo]
[LWN.net]

Sections:
 Main page
 Security
 Kernel
 Distributions
 On the Desktop
 Development
 Commerce
 Linux in the news
 Announcements
 Linux History
 Letters
All in one big page

See also: last week's Kernel page.

Kernel development


The current kernel release is 2.4.11, which was released on October 9. Unlike some 2.4 releases, this one actually seems to be dedicated to stabilizing things; with the exception of some block layer, superblock, and partition changes, 2.4.11 consists mostly of bug fixes and driver updates.

2.4.11 does also contain the code that marks the kernel "tainted" if non-free loadable modules are used. In some cases, users are getting warnings when using entirely free code. It's nothing to be worried about, there just is still some cleaning up to do there.

(Update: see the 2.4.12 announcement, which came out just after LWN's publication, for an update on the "sorry excuse for a kernel" that Linus now calls 2.4.11).

Alan Cox's latest patch is 2.4.10-ac11, which contains a large set of fixes and updates. According to Alan, "The 2.4.10-ac tree now seems pretty solid."

For 2.0 users, David Weinehall has released 2.0.40-pre2, which adds another set of fixes to this ancient kernel. Some difficulties with this patch have been reported, so many users may want to wait for -pre3.

Where does kernel development stand? The current kernel development situation is, perhaps, unprecedented in Linux's history. It's interesting to look at what's going on:

  • There are currently two "stable" 2.4 kernel trees, which differ significantly. The two competing virtual memory implementations are the biggest difference, of course, but there are others as well. The "-ac" series contains a number of changes which have not, yet, made it into the Linus kernel. Merging changes has been made more difficult by the degree of divergence between the kernels, meaning that stuff is moving into the Linus tree at a slower pace.

    There is also an increasing level of grumbling from various kernel developers, who are finding themselves having to support two different stable trees. There is a fair amount of work (example) going into that support.

  • There has been no development kernel since last January. Given that the kernel was (kind of) in a feature freeze for some time before the 2.4.0 release, it has been over a year since there has been a real target for new kernel developments. It's no wonder that development-like things are finding their way into stable kernel releases.
Some of the troubles, certainly, could be addressed by opening up the 2.5 series. With a real (single) development kernel to hack on, people would be less inclined to try to get bleeding-edge stuff into a 2.4 kernel.

But that still leaves the question of what will happen with the 2.4 kernel. Linus generally leaves the stable series behind when he starts a new development kernel; in the recent past, the responsibility for the stable kernel has then passed on to Alan Cox. But Alan is maintaining a different, 2.4-based tree, and intends to continue doing so. He states that it will take "another 5 or 6 releases" to get the new VM truly stable, and is thus unlikely to adopt it into his kernel for some time.

Interestingly, though, most distributors base their kernels off the "ac" tree, not the mainline Linus kernel. Conceivably, once Linus moves on to 2.5, his 2.4 series could begin to look like a dead end. That may look like an unlikely outcome, but, unless somebody backs down on the VM issue, a unified 2.4 is looking unlikely in the near future.

Why no 'text file busy' with shared libraries? Linux, like most Unix-like systems, will not allow an executable file to be overwritten if it is currently being run by a process. Many people who build or install programs have been frustrated by the resulting "text file busy" message. The reasoning behind this restriction is clear: the file in question is in use as the backing store for one or more live virtual memory areas; changing it could easily corrupt the processes using those areas.

An interesting question was asked on the kernel list: why is there no similar restriction applied to shared library files? They are mapped in the same way as executables, and form a part of a running process in the same way. But the kernel will happily allow a user with appropriate permissions to overwrite an active shared memory, with the result that a running process could find itself with some pages from the old version, and others from the new. Anybody who has ever made an incautious shared library update can attest that the results are unpleasant.

Some systems, such as those based on the Mach kernel, handle this problem with a special flag (MAP_COPY) to the mmap() system call. If a file (such as a shared library) is mapped with MAP_COPY, the mapping process gets a virtual copy that will never change. Even if the file is overwritten, the process will see a consistent view of the older version. Linus, however, doesn't like that idea (to put it mildly). His objections have to do with the difficulties of implementing MAP_COPY - it adds a great deal of complexity to a number of operations, and he sees little or no benefit. So MAP_COPY is unlikely to show up in the Linux kernel.

Another solution is to block writes to the file, as is already done with executables. Linux does have a flag (MAP_DENYWRITE) which requests this behavior, but it is almost always ignored by the VM subsystem. To do otherwise would be a security problem; if a process with read access to a file can deny write access to other processes, there are a number of denial of service possibilities. The classic exploit is to map the utmp file in this manner, thus denying logins. The password file and system logs are a couple of other possible targets for such an attack.

There is, perhaps, a solution in sight, however. As proposed by Eric Biederman, the MAP_DENYWRITE flag could be safely recognized from user space if an additional test is met: the mapping process has execute access to the file. Once shared library images are protected with the execute bit, it will no longer be possible to overwrite them when they are in use. A patch along these lines will likely appear in a future kernel.

Other patches and updates released this week include:

  • Keith Owens has released version 1.4 of the 2.5 kernel build system.

  • Greg Kroah-Hartman has released a new version of the Compaq Hotplug PCI driver.

  • Rik van Riel has posted a patch for the "ac" kernel series which makes the system reclaim cache pages more aggressively. This should improve performance in situations where a great deal of I/O is happening. There is another patch from Rik which is intended to improve interactive performance. Rik is looking for testers for both patches.

  • A new 64-bit PCI patch has been released by David Miller.

  • The Functionally Overloaded Kernel Patch is at version 2.3.0.

  • kdb 1.9 for the 2.4.11 kernel was released by Keith Owens.

  • Jens Axboe has released a new version of his patch enabling bounce-free DMA from high-memory buffers.

  • The October 10 version of the security module patch was released by Chris Wright.

  • Steve Best has released version 1.0.7 of the IBM Journaling filesystem.

Section Editor: Jonathan Corbet


October 11, 2001

For other kernel news, see:

Other resources:

 

Next: Distributions

 
Eklektix, Inc. Linux powered! Copyright © 2001 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds