"Ok, the merge window has closed, and 2.6.22-rc1 is out there," Linus Torvalds announced on the Linux Kernel Mailing List. He noted that there were a large number of changes, "almost seven thousand files changed, and that's not double-counting the files that got moved around." As to what was changed, Linus summarized, "architecture updates, drivers, filesystems, networking, security, build scripts, reorganizations, cleanups.. You name it, it's there." He went on to add:
"You want a new firewire stack? We've got it. New wireless networking infrastructure? Check. New infiniband drivers? Digital video drivers? A totally new CPU architecture (blackfin)? Check, check, check.
"That said, I think (and certainly hope) that this will not be nearly as painful as the big fundamental timer changes for 2.6.21, and while there are some pretty core changes there (like the new SLUB allocator, which hopefully will end up replacing both SLAB and SLOB), it feels pretty solid, and not as scary as ripping the carpet from under the timer infrastructure."
From: Linus Torvalds [email blocked] To: Linux Kernel Mailing List [email blocked] Subject: Linux 2.6.22-rc1 Date: Sat, 12 May 2007 20:20:35 -0700 (PDT) Ok, the merge window has closed, and 2.6.22-rc1 is out there. The diffstat and shortlogs are way too big to fit under the kernel mailing list limits, and the changes are all over the place. Almost seven thousand files changed, and that's not double-counting the files that got moved around. Architecture updates, drivers, filesystems, networking, security, build scripts, reorganizations, cleanups.. You name it, it's there. You want a new firewire stack? We've got it. New wireless networking infrastructure? Check. New infiniband drivers? Digital video drivers? A totally new CPU architecture (blackfin)? Check, check, check. That said, I think (and certainly hope) that this will not be nearly as painful as the big fundamental timer changes for 2.6.21, and while there are some pretty core changes there (like the new SLUB allocator, which hopefully will end up replacing both SLAB and SLOB), it feels pretty solid, and not as scary as ripping the carpet from under the timer infrastructure. So give it a good testing. We'll see how the regression tracking ends up working, but in order to actually track that, we want people actively testing -rc1 and making good reports! Linus
| Why Windows is better than Linux | 53 minutes ago | Linux general |
| magical mounts | 1 hour ago | Linux kernel |
| Problem in scim in Fedora 9 | 2 hours ago | Linux general |
| The new Western Digital power saving drives | 2 hours ago | Hardware |
| Battery Maximizer Software | 23 hours ago | Linux kernel |
| windows folder creation surprise | 1 day ago | Windows |
| Firewall | 1 day ago | OpenBSD |
| IP layer send packet | 2 days ago | Linux kernel |
| dtrace for linux available | 2 days ago | Linux kernel |
| Unable to mount ramdisk image using UBoot while upgrading to 2.6.15 kernel for a MPC8540 based target | 2 days ago | Linux kernel |
revoke revokeat frevoke
Unfortunately, one of the things that didn't get the revoke() family of syscalls. For those unfamiliar, this call essentially "pulls the rug" under a process that has the revoked file open; any further attempts to operte on it - other than close - will error out; attempt to access though mmap will SIGBUS. This is useful for cleanly unmounting file systems; various security tasks (SLIM, in -mm, use this), SELinux could use this too in MLS mode as well.
Re: revocation calls, mandatory access controls
Just a major change in standard POSIX semantics, nothing to worry about.
In terms of security, the standard semantics are "discretionary" ... once you have access, it's up to you to do what you want with it, ranging from nothing to handing it out to one of the Bad Guys (Bush administration, etc).
The alternative "mandatory" access control is more attuned to those revocation calls, and as the original poster noted, part of "Multi-level Secure" (MLS) models too. That's where the system can prevent you from doing stuff with information you have. Like not being able to disclose top-secret information to someone not cleared for it. Or in a business context, not being able to disclose financials before end-of-quarter publication date.
I'd certainly *HOPE* nobody rushes towards adding mandatory access controls. Major changes like that need thought that I don't necessarily see has gone into those particular calls...
Is it really a huge change in semantics?
What are the POSIX semantics for disk failure? Just hang until the disk unfails magically? What about power failure? Magically move everything to NVRAM to be restored w/out a hiccup when the power comes back? When something fails and you can no longer get to it, your inability to get to it seems pretty inevitable. Disk cables and power switches[*] are mandatory access controls. :-)
My understanding of revoke() etc. was that it was analagous to hardware failure. That is, some resource is going away (perhaps due to a transient failure), and so rather than keep a fiction around that processes might be able to access the resource in the future, treat the loss of access to a resource similarly to a catastrophic failure of that resource. That seems entirely reasonable to me.
[*]And before someone gets smart with me about modern computers' power buttons being more advisory than mandatory, just replace "power switch" with "power cable" or "battery pack" as your platform dictates.
POSIX *does* dictate what to
POSIX *does* dictate what to do in case of hardware failure. open(), read(), write(), all can return errors. And access to mmap'ed memory can trigger a signal.
I don't see revoke() as adding any new semantics. It just makes it more convenient for users to get the old hardware failure semantics when they need them.
Anyway, what nefarious consequences do you see happening if people get the ability to revoke() access to files for processes that they own?
Architecture updates,
Architecture updates, drivers, filesystems, networking, security, build
scripts, reorganizations, cleanups.. You name it, it's there.
Revoke()?
Is that syscall defined? Having this on Linux would be absolutely *wonderful*! You don't know how many times I've had to reboot uncleanly because of zombie processes hanging on files on a mounted filesystem
Yes, it is in -mm (actually
Yes, it is in -mm (actually there are 2 calls: revokeat, and frevoke)
revoke-add-documentation.patch
revoke-core-code-break-cow-fixes.patch
revoke-core-code-break-cow-for-private-mappings.patch
revoke-core-code-change-revoke_table-to-fileset-and-revoke_details.patch
revoke-core-code-do_revoke-error-handling.patch
revoke-core-code-fix-shared-mapping-revoke-revoke-only-revoke-mappings-for-the-given-inode.patch
revoke-core-code-fix-shared-mapping-revoke.patch
revoke-core-code-fs-revokec-cleanups-and-bugfix-for-64bit-systems.patch
revoke-core-code-generic_file_revoke-stub-for-nommu.patch
revoke-core-code-mapping-revocation.patch
revoke-core-code-misc-fixes.patch
revoke-core-code-move-magic.patch
revoke-core-code-only-fput-unused-files.patch
revoke-core-code-rename-to-can_revoke_filevma.patch
revoke-core-code-revoke-no-revoke-for-nommu.patch
revoke-core-code-slab-allocators-remove-slab_debug_initial-flag-revoke.patch
revoke-core-code.patch
revoke-special-mmap-handling-vs-fault-vs-invalidate.patch
revoke-special-mmap-handling.patch
revoke-support-for-ext2-and-ext3.patch
Running out of allocators!
SLUB better hold us for awhile... there's only SLIB and SLEB left (and maybe SLYB), but those just sound silly. ;-)
Concur
ETLA BLUS
Timer changes for x86_64 in 2.6.22 ?
So if the merge windows has closed, does that mean that dynticks and a tickless kernel for x86_64 are not going to make it into 2.6.22 ?
I'd be interested to know if anyone's got any clue as to when they might be merged.
I'm pretty sure it's doing wonders for my x86 laptop's battery, but I've got a virtualisation project to test it with on AMD64. Ta.
AFAIK tickless kernel for
AFAIK tickless kernel for x86_64 will be merge into 2.6.23
Does anyone know if 2.6.22
Does anyone know if 2.6.22 will include Ingo's CFS-scheduler ?
No as far as I know. I can
No as far as I know. I can be wrong though.