On the Desktop
Linux in the news
All in one big page
See also: last week's Kernel page.
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:
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:
Section Editor: Jonathan Corbet
October 11, 2001