Kernel release status

[Posted June 23, 2004 by corbet]

The current 2.6 kernel is 2.6.7; the first 2.6.8 prepatch has not yet been released as of this writing. There is, however, a large pile of patches in Linus's BitKeeper tree, including support for new Apple PowerBooks, more sparse annotations, some netfilter improvements, some kbuild work, a new wait_event_interruptible_exclusive() macro, support for the O_NOATIME flag in the open() call, sysfs knobs for tuning the CFQ I/O scheduler, mirroring and snapshot targets for the device mapper, the removal of the PC9800 subarchitecture, reiserfs data=journal support, preemptible kernel support for the PPC64 architecture, and many fixes and updates.

The current prepatch from Andrew Morton is 2.6.7-mm1; recent additions to -mm include a new knob for controlling how aggressively the system reclaims VFS caches when memory gets tight, a memory allocation tweak to improve DMA segment merging (see below), and various fixes.

The current 2.4 prepatch is 2.4.27-rc1, which was released by Marcelo on June 19. Only a small number of fixes have gone in since the last prepatch. Now is the time for those interested in a stable 2.4.27 release to do some testing.

to post comments

NO_ATIME?

Posted Jun 25, 2004 22:13 UTC (Fri) by Ross (guest, #4065) [Link] (2 responses)

I'd like to hear a little more about this. Can any use use this flag? If
so does it only work when reading files by that user? If no there are some
security implications because access times can no longer be trusted.

(Yes, they can't be trusted now when the user can edit the inode time info
but that isn't the case for system files.)

NO_ATIME?

Posted Jul 1, 2004 12:31 UTC (Thu) by Peter (guest, #1127) [Link]

(Yes, they can't be trusted now when the user can edit the inode time info but that isn't the case for system files.)

I can't think of a lot of reasons why hiding that you have accessed a file really is security-sensitive. Arbitrarily changing the atime or mtime, yes, that's something you don't want people doing to files they don't have permissions to - but merely not updating the atime - that seems rather less serious. It's not like the atime gives you a real audit trail, after all - it doesn't say who last read a file.

NO_ATIME?

Posted Jul 1, 2004 13:35 UTC (Thu) by cesarb (subscriber, #6266) [Link]

From the glibc manual:

int O_NOATIME Macro
If this bit is set, read will not update the access time of the file.
See File Times. This is used by programs that do backups, so that
backing a file up does not count as reading it. Only the owner of the
file or the superuser may use this bit.

So, only the owner of the file or the superuser can use this flag.

http://lkml.org/lkml/2004/6/11/192 has the patch and discussion.

device-mapper snapshot target

Posted Jul 2, 2004 15:08 UTC (Fri) by ringerc (subscriber, #3071) [Link]

It is an absolute delight to see snapshot support for device-mapper
finally going in to the stable kernel.

I had to upgrade my company's core server to 2.6 fairly early on to solve
some serious disk I/O scheduling problems, and discovered that LVM2 not
only lacked snapshot support, but that this lack was undocumented. Even
better, LVM2 broke rather badly if the admin unwittingly tried to use the
snapshot feature - in my case, forcing a SERVER REBOOT in production time
to restore the logical volumes to a usable state.

With this support in the kernel, my mail spool backups will be safe
again :-) . More importantly, LVM2 will be (at least from my perspective)
back up to the functionality of LVM1.

So - thanks to the device-mapper and LVM developers. I'm still bewildered
that snapshot was allowed to remain dangerously broken for so long, but
I'm delighted to see it's now working and going into the stable kernel.