The current 2.6 kernel is 126.96.36.199
the availability of the
2.6.8 allegedly stable kernel on August 13.
Unfortunately, it turned out to be a true "Friday the 13th" release with a
fatal bug in the NFS code, so 188.8.131.52 was rushed out to fix it. This
is the first time that the kernel has used a four-entry version number.
Changes since -rc4 include the "Khazad" crypto algorithm, some added
permissions checking on raw SCSI commands from user space (see below), and
of the fcntl()
file operations method. For those just tuning in,
changes from 2.6.7 include snapshot and mirror support in the
device mapper, unbelievable numbers of "sparse" annotations, a bunch of
read-copy-update performance improvements, 64-bit SuperH support, some
security fixes, a reworked symbolic link lookup mechanism (which will
eventually enable raising the maximum link depth), and lots of fixes. The
has the details; the
is also out there for the
No patches have been added to Linus's BitKeeper repository since the
The current prepatch from Andrew Morton is 184.108.40.206-mm1. Recent changes to -mm include kprobes
("Generally we prefer to not merge infrastructure into the kernel
unless it has in-kernel users. kprobes is exceptional, in that its
applications are all custom-written to solve a particular
problem."), the removal of the single-array scheduler patch, a waitid()
system call implementation, and lots of fixes.
The current 2.4 prepatch is 2.4.28-pre1, which was released by Marcelo on August 15.
Additions include a big serial ATA update, the Khazad crypto algorithm,
some networking updates, and a handful of fixes.
Comments (5 posted)
Kernel development news
Some kernel interfaces last longer than others. The fcntl()
method is one of the others. It was added to the file_operations
structure in 2.6.6 with the purpose of
giving low-level filesystems and device drivers an opportunity to look at
the command being executed from an fcntl()
system call and,
possibly, do something different. The
immediate motivation was allowing the NFS code to disallow the combination
of the O_APPEND
flags, since those two modes
cannot work together in that filesystem. Since then, the CIFS filesystem
also has made use of it to better handle the F_NOTIFY
getting directory notifications from the remote server.
In 2.6.8, that operation is gone again. The thinking is that the
file_operations structure did not really need another
general-purpose, multiplexed operation like fcntl(). So the
method was replaced with two new, carefully-focused methods. The first is:
int (*check_flags)(int flags);
This operation, if present, will be called in response to an
fcntl(F_SETFL,...) system call. It can look at the flags passed
in from user space and ensure that they make sense for the device or
filesystem in question.
The other new operation is:
int (*dir_notify)(struct file *filp, unsigned long arg);
This is the new method used by CIFS to handle F_NOTIFY
requests. All other fcntl() operations are handled in the core
VFS code, as usual.
The patch as merged by Linus fixed the NFS
and CIFS code to use the new
methods. Unfortunately, nobody tested the NFS changes before the patch was
merged, and this change went in just before the final 2.6.8 release came
out. The result was an NFS implementation which crashed the kernel, and
the need for a quick 220.127.116.11 release.
Comments (10 posted)
By far the loudest chorus of complaints about the 18.104.22.168 kernel comes from
users who have found that they can no longer burn CDs. In most cases, the
problem can be worked around by running the recording program from a root
shell (setuid is not sufficient), but
that is an unsatisfying alternative for many. Why, ask inquiring minds,
did CD recording have to break with the new kernel?
It's all a matter of trying to get the permissions right. Burning a CD
requires sending a number of special-purpose SCSI commands to the drive, so
the operation is performed outside of the regular I/O paths. But once you
can send arbitrary commands, you can do more than write CDs. In pushing
for changes, Alan Cox put it this way:
With the current code I can destroy all your hard disks given read
access to the drive. With checks on writable I can destroy all your
hard disks/cdroms as appropriate with write access. Destroy here
means "dead, defunct, pushing up the daisies, go order a new one
kind of dead".
Seeing this outcome as undesirable, Linus threw in a patch shortly before releasing 2.6.8. This
patch creates an array of known SCSI commands, associating each with "safe
for read" and "safe for write" flags. Those flags are tested when a
process attempts to execute the given command. If the device has been
opened for read access, the set of allowed commands is relatively small:
read, request sense, play CD, etc. A process with write access can execute
more commands, but not the whole set. Any command not explicitly flagged
as safe for the given open mode is restricted to processes with the
CAP_SYS_RAWIO capability - root, for all practical purposes.
This patch broke CD burning in multiple ways. Users of growisofs were
burned (so to speak) because that utility opens the device for read access.
That should never have worked, but did until now; fixing that problem will
require a patch to the application. Beyond that, however, is the simple
fact that numerous SCSI commands needed for CD burning were omitted from
the "safe for write" list. These vary from locking the door to "send OPC,"
"blank", and many others. Enabling CD writing from an unprivileged process
with write access to the drive will require adding several commands to the
Unfortunately, expanding the list in that manner can bring back the
original problem. Many commands which are safe to execute in one context
can destroy data, firmware, or hardware in other contexts. And it can be
very hard for the kernel to tell the difference between the two. There has
been talk of expanding the checking framework to better understand the
target device's operating modes and, perhaps, giving high- or low-level
drivers a say in the decision. Down that road lies complexity, however,
and it would be hard to reach a point where the developers could declare
victory and call the problem solved. It may well be that, despite other
faults in his reasoning on CD recording, Jörg Schilling got
it right when he suggested that the most secure mode of operation is to
simply restrict device access and run the CD recording application in a
Comments (20 posted)
Power management remains one of the unfinished jobs from the 2.5
development series. Many of the pieces are in place, including the whole
device model infrastructure, but the kernel still lacks a comprehensive,
working power management subsystem. There are signs that things are
starting to happen, but it seems that the developers still lack a clear
idea of how they want to go forward.
Back on August 9, Patrick Mochel posted a
patch aimed at improving the power management subsystem. It brought
significant changes to the device model, including:
- Two power management methods were added to the class subsystem.
Until this point, classes had not been part of the power management
code at all; they are, instead, a way of exporting device information
in a functional organization. The rationale behind putting power
management functions in classes was that the higher-level code would
better understand how to "quiesce" a device in preparation for a
power state change.
- Three new power management methods were be added to the device model
representation of a bus (struct bus_type). These were
pm_save() (save state prior to a state transition),
pm_restore() (restore state afterward), and
pm_power() (perform an actual state change). These methods
would replace the current suspend() and resume() bus
methods, and the equivalent methods associated with struct
device_driver. The idea is to move all power management tasks
firmly into the bus-level code, and to let that code pass things on to
low-level drivers as appropriate.
- Each device would get two new arrays. One of these
(pm_supports) lists all of the power management states
supported by the device, in that particular device's (usually
bus-specific) terms. The second array (pm_system) is a
simple mapping from the power states understood system-wide into the
equivalent device states. These states are described by the new
pm_state structure, and sysfs interfaces exist to query the
supported states and to transition between them.
The resulting discussion implied a lot of changes to this patch; among
other things, the idea of using the class layer to quiesce devices was
controversial. An updated version of the patch has not been posted,
Pavel Machek, meanwhile, has been trying to address a much smaller piece of
the problem: confusion over what the power management states really mean.
The power management code itself uses a set of states roughly related to
those defined in the ACPI specification, but other parts of the system (PCI
drivers, for example) have a different set of states. The current power
management methods take a u32 state value, and it is far from
clear what kind of state is intended.
Pavel's patch tries to address this problem
by creating a new enum type called system_state. The
bus- and driver-level power management methods are modified to accept a
parameter of this type, so that it is clear that (1) the power
management core's state values are being used, and (2) the parameter
describes the state to which the entire system is changing. It clears up a
core ambiguity without otherwise changing how things work.
Even this change is controversial, however. The largest concern is that,
eventually, it is expected that the drivers will need more information than
just the target system state. So, it is suggested, the type of the
parameter should be a structure pointer rather than a simple scalar value.
But nobody has really figured out what should go into the structure yet.
Getting it right the first time matters in this case. It is generally
accepted that fixing power management will require a driver API change, and
that, potentially, all drivers in the kernel (and out of tree as well) will
have to be changed at once. Developers are resigned to this change - but
they would really rather only do it once. So, says Patrick, it's better to wait:
Why be hasty? We need to do it right and do it once. If that means
a couple of more weeks and several more emails, than so be it.
Otherwise, we'll be stuck with a sub-par solution for who knows how
What this means is that the discussion is likely to continue for a while -
and that an upgraded power management system will not be ready until
2.6.10, at best. Linux users, who have waited a long time for better power
management, can probably manage to be patient for a little while yet.
Comments (none posted)
Efforts to track down and eliminate sources of latency in the 2.6 kernel
continue. It seems, however, that most of the low-hanging fruit has been
found; with the current iteration of the voluntary preemption patch, the
remaining problems are rare and relatively hard to track down. So Ingo
Molnar built himself a new tool
to help with
those harder cases.
Ingo's problem with the previous preempt timing patch was that, while it
showed where a lengthy latency took place, it yielded little information
about what was happening during the high-latency event. So he adapted the
profiling mechanism to bring a little light to the situation. With the
latency tracing option turned on, a little tracing function gets called as part of
every kernel function call. This trace code stores the time of the call
into a large (4000 entries), per-CPU array. If the kernel avoids
scheduling for too long, that array of function call information gets copied into a
static array which is made available via /proc/latency.
Ingo included some example output with his patch:
preemption latency trace v1.0
latency: 121 us, entries: 1032 (1032)
process: default.hotplug/1470, uid: 0
nice: -10, policy: 0, rt_priority: 0
0.000ms (+0.000ms): page_address (kmap_high)
0.000ms (+0.000ms): page_slot (page_address)
0.000ms (+0.000ms): flush_all_zero_pkmaps (kmap_high)
0.000ms (+0.000ms): set_page_address (flush_all_zero_pkmaps)
0.118ms (+0.000ms): page_slot (set_page_address)
0.118ms (+0.000ms): check_preempt_timing (sub_preempt_count)
The output shows the function call, and, in parentheses, the caller of each
function. In this case, the output identifies
flush_all_zero_pkmaps() as the real villain.
Other changes to this patch include making hardware and software interrupts
(which have been redirected into kernel threads) preemptible by default ("I
reviewed a number of softirq users and it appears to be safe"), and,
of course, the breaking up of more code which holds locks for too long.
Comments (none posted)
Patches and updates
Core kernel code
Filesystems and block I/O
Page editor: Jonathan Corbet
Next page: Distributions>>