Linux kernel version 2.6.23; not yet released

1. Short overview (for news sites, etc)

2.6.23 includes the new, better, fairer CFS process scheduler, a simpler read-ahead mechanism, the lguest 'Linux-on-Linux' paravirtualization hypervisor, part of the XEN virtualization solution, variable process argument lenght, SELinux protection for exploiting null dereferences using mmap, XFS and ext4 improvements, PPP over L2TP support, the 'lumpy' reclaim algorithm, a userspace driver framework, the O_CLOEXEC file descriptor flag, splice improvements, the fallocate() syscall

2. Important things (AKA: ''the cool stuff'')

2.1. The CFS process scheduler

The new process scheduler, a.k.a CFS (Completely Fair Scheduler), has generated much noise in some circles due to the way this scheduler has been chosen over it's 'competitor' RDSL. A bit of story is needed to clarify what happened and what CFS does compared to the old scheduler.

Long time ago, during the development of Linux 2.5, the 'O(1)' process scheduler from Ingo Molnar was merged to replace the process scheduler inherited from 2.4. The O(1) scheduler was mainly designed to fix the scalability issues in the 2.4 process scheduler - the improvements were so big, that the O(1) scheduler was one of the most frequently backported features to 2.4 in commercial Linux distributions. However, the algorithms in charge of scheduling the processes did not receive so much attention - the main goal of the new scheduler was to solve the scalability issues from the ground up, where as the process scheduling was considered good enough, or at least it wasn't perceived as a critical issue. Those algorithms can make a huge difference in what the users perceive as 'interactivity'. For example, if a process - or more than one - starts an endless loop and due to those CPU-bound loopers and the process scheduler doesn't assign as much CPU as necessary to the already present non-looping processes in charge of implementing the user interfaces (X.org, kicker, firefox, openoffice.org, etc), the user will perceive that the programs don't react to his actions very smoothly. Worse, in the case of music players your music could skip.

The O(1) scheduler, just like the previous scheduler, tried to handle those situations as well as possible, and generally, they did a good job in most of cases. However, many users reported corner cases and not-so-corner cases where the new scheduler didn't worked as expected. One of those people was Con Kolivas, and despite his inexperience in the kernel hacking world, he tried to fine-tune the scheduling algorithms, without replacing them. His work was a big success, and his patches found a way into the main kernel.

He didn't stop there. Con found that the 'interactivity estimator' - a piece of code used by the process scheduler to try to decide which processes were more 'interactive' and hence needed more attention so that the user would perceive a smoother behaviour on their desktops - caused more problems than it solved. Contrary to its original purpose, the interactivity estimator couldn't fix all the 'interactivity' problems present in the process scheduler, and trying to fix one would open another issue. It was the typical case of an algorithm using statistics to try to predict the future with heuristics, and failing at it.

Con designed a new scheduler that killed all the failed interactivity estimations. Instead, his scheduler was based on the concept of fairness while conserving the 'O(1)-ness' of the mainline scheduler: processes are treated equally and are given same timeslices (see [http://lwn.net/Articles/224865/ this LWN article for more details on this scheduler]), and the scheduler doesn't care or even try to guess if the process is CPU bound or IO-bound (interactive). This scheduler improved the user's perceived smoothness to unprecedented levels.

This scheduler was the one that was going to get merged, but Ingo Molnar (the O(1) creator) created his own new scheduler, called CFS (alias for 'Completely Fair Scheduler'), taking as the basic design element the 'fairness' idea that Con's scheduler had proved to be superior. The CFS scheduler has some differences compared to Con's RDSL: Instead of runqueues (that are used in both RDSL and mainline O(1)), it uses a time-ordered rbtree to build a 'timeline' of future task execution, to try to avoid the 'array switch' artifacts that both the vanilla and the RSDL scheduler can suffer. It also uses nanosecond granularity accounting and does not rely on any jiffies or other HZ detail; in fact it does not have the notion of 'timeslices' and has no heuristics whatsoever (read [http://lwn.net/Articles/230574/ this LWN article for more details on CFS design]). CFS has been chosen as replacement for the current 'O(1)' scheduler over RDSL - surprisingly this choice has generated much noise. It must be noticed that both RDSL and CFS are great schedulers, much better than the one in mainline, and that it was Con who pioneered the idea of using the concept of 'fairness' over the 'interactivity estimations', but that doesn't mean that CFS didn't deserve to get merged instead of RDSL (neither the contrary, if that had been the case).

2.2. On-demand read-ahead

Click to read a [http://lwn.net/Articles/235164/ recommended LWN article about on-demand read-ahead]

On-demand read-ahead is an attempt to simplify the [http://lwn.net/Articles/155510/ Adaptive read-ahead patches]. On-demand readahead reimplements the Linux readahead functionality, removing a lot of complexity from the current system and making it more flexible. This new system maintains the same performance for trivial sequential/random reads, it improves the sysbench/OLTP MySQL benchmark up to 8%, and performance on readahead thrashing gains up to 3 times. There are more read-ahead patches based in this infrastructure pending and further work could be done in this area as well, so expect more improvements in the future. Detailed design document and benchmarks can be found [http://lwn.net/Articles/235181/ here].

2.3. fallocate()

Click to read a [http://lwn.net/Articles/240571/ recommended LWN article about fallocate()]

fallocate() is a new system call which will allow applications to preallocate space to any file(s) in a file system. Applications can get a guarantee of space for particular file(s) - even if later the system becomes full. Applications can also use this feature to avoid fragmentation to certain level in many filesystems (fe: it avoids the fragmentation that can happen in files that are frequently increasing its size) and thus get faster access speed.

Currently, glibc provides the POSIX interface called [http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html posix_fallocate()] which can be used for similar cause. Though this has the advantage of working, it is quite slow (since it writes zeroes to each block that has to be preallocated). Without a doubt, file systems can do this more efficiently within the kernel, by implementing the proposed fallocate() system call, and this what 2.6.23 does. It is expected that posix_fallocate() will be modified to call this new system call first and in case the kernel/filesystem does not implement it, it should fall back to the current implementation of writing zeroes to the new blocks.

In 2.6.23, only ext4 and ocfs2 are adding support for the fallocate() interface.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=97ac73506c0ba93f30239bb57b4cfc5d73e68a62 (commit)]

2.4. Virtualization: lguest and Xen

Linux has good virtualization support thanks to the paravirtualization and KVM support. 2.6.23 is improving the support of the trend-of-the-decade by adding lguest and Xen support support - both of them based in the paravirt_ops infrastructure.

2.4.1. lguest

Click to read a [http://lwn.net/Articles/218766/ recommended article about lguest]

lguest is a simple hypervisor for Linux on Linux (in other words, it allows to run linux -only linux- guests) based in the paravirt_ops infrastructure. Unlike kvm it doesn't need VT/SVM hardware. Unlike Xen it's simply "modprobe and go". Unlike both, it's 5000 lines and self-contained.

The goal of his author, Rusty Russell, was not to create the singlest and greatest hypervisor ever, but rather create a simple, small (5000 lines of code) hypervisor example to show the world how powerful the paravirt_ops infrastructure is. Performance is ok, but not great (-30% on kernel compile), precisely because it was written to be simple. But given its hackability, it may improve soon. The author encourages people to fork it and try to create a much better hypervisors: Too much of the kernel is a big ball of hair. lguest is simple enough to dive into and hack, plus has some warts which scream "fork me!". A 64-bit version is also being worked on.

Lguest host support (CONFIG_LGUEST)can be compiled as a module (lg.ko). This is the host support - one you load it, your kernel will be able to run virtualized lguest guests. But kernel guests need to compile lguest guest support in order to be able to run under the lguest host. The configuration variable that enables the guest support is CONFIG_LGUEST_GUEST - but that option will be enabled automatically once you set CONFIG_LGUEST to 'y' or 'm'. This means that a kernel compiled with lguest host support does also get lguest guest support. In other words, you can use the same kernel you use to be a host as guest kernel. In order to load and run new guests, you need a loader userspace program. The instructions and the program can be found at Documentation/lguest/lguest.txt

Code: [http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/lguest;hb=HEAD drivers/lguest], [http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=Documentation/lguest;hb=HEAD Documentation/lguest]

2.4.2. Xen

Part of Xen has been merged. The support included in 2.6.23 will allow the kernel to boot in a paravirtualized environment under the Xen hypervisor. But support for the hypervisor is not included - this is only guest support, no dom0, no suspend/resume, no ballooning. It's based in the paravirt_ops infrastructure.

Code: [http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/xen;hb=HEAD (part 1, drivers/xen], [http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/i386/xen;hb=HEAD part 2, arch/i386/xen)]

2.5. Variable argument length

From a [http://interviews.slashdot.org/interviews/04/10/18/1153211.shtml?tid=189 Slashdot interview to Rob Pike]: I didn't use Unix at all, really, from about 1990 until 2002, when I joined Google. (I worked entirely on Plan 9, which I still believe does a pretty good job of solving those fundamental problems.) I was surprised when I came back to Unix how many of even the little things that were annoying in 1990 continue to annoy today. In 1975, when the argument vector had to live in a 512-byte-block, the 6th Edition system would often complain, 'arg list too long'. But today, when machines have gigabytes of memory, I still see that silly message far too often. The argument list is now limited somewhere north of 100K on the Linux machines I use at work, but come on people, dynamic memory allocation is a done deal!

While Linux is not Plan 9, in 2.6.23 Linux is adding variable argument length; no more "argument list too long" errors.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba (commit)]

2.6. PPP over L2TP

Linux 2.6.23 adds support for PPP-over-L2TP socket family. L2TP is a protocol used by ISPs and enterprises to tunnel PPP traffic over UDP tunnels. L2TP is replacing PPTP for VPN uses. The kernel component included in 2.6.23 handles only L2TP data packets: a userland daemon handles L2TP the control protocol (tunnel and session setup). One such daemon is [http://openl2tp.sourceforge.net/ OpenL2TP]

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=342f0234c71b40da785dd6a7ce1dd481ecbfdb81 (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cf14a4d06742d59ecb2d837a3f53bb24d1ff9acb 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3557baabf28088f49bdf72a048fd33ab62e205b1 3)] Documentation: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=58e50a904ec78caf4ca938801c031413b0d3f962 (commit)]

2.7. Autoloading of ACPI kernel modules

With Linux 2.6.23, the ACPI modules are exporting the device table symbols in the drivers so that udev can automatically load them through the usual mechanisms.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8c8eb78f673c07b60f31751e1e47ac367c60c6b7 (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29b71a1ca74491fab9fed09e9d835d840d042690 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ba90e3a87c46500623afdc3898573e4a5ebb21b 3)]

2.6.23 also adds DMI/SMBIOS based module autoloading to the Linux kernel. The idea is to load laptop drivers automatically (and other drivers which cannot be autoloaded otherwise), based on the DMI system identification information of the BIOS. Right now most distros manually try to load all available laptop drivers on bootup in the hope that at least one of them loads successfully. This patch does away with all that, and uses udev to automatically load matching drivers on the right machines.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4f5c791a850e5305a5b1b48d0e4b4de248dc96f9 (commit)]

2.8. 'Lumpy' reclaim

Click to read a [http://lwn.net/Articles/211199/ recommended LWN article which touches the 'lumpy' reclaim feature]

High-order petitions of free memory in the kernel (IOW, petitions of free memory that are bigger than one memory page and must be contiguous) can fail easily due to the memory fragmentation when there's very few free memory left: When the memory management subsystem tries to free some memory to make room for the petition, it frees pages in LRU (Least Recently Used) order, and pages freed in LRU order are not neccesarily contiguous - rather, they're freed according to its recency. So the allocation may still be satisfied.

The 'lumpy' reclaim modifies to reclaim algorithm to improve this situation: When it needs to free some pages, it tries to free the pages contiguous to the first choosen page in the LRU, ignoring the recency, improving the posibilities of findind a contiguous block of free memory.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5ad333eb66ff1e52a87639822ae088577669dcf9 (commit)]

2.9. Movable Memory Zone

It is often known at allocation time whether a page may be migrated or not. This feature adds a flag called __GFP_MOVABLE to the memory allocator and a new mask called GFP_HIGH_MOVABLE. Allocations using the __GFP_MOVABLE can be either migrated using the page migration mechanism or reclaimed by syncing with backing storage and discarding. This feature also creates a memory zone called ZONE_MOVABLE that is only usable by allocations that specify both __GFP_HIGHMEM and __GFP_MOVABLE. This has the effect of keeping all non-movable pages within a single memory partition while allowing movable allocations to be satisfied from either partition. More details in the commit links.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=769848c03895b63e5662eb7e4ec8c4866f7d0183 (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2a1e274acf0b1c192face19a4be7c12d4503eaaf 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=396faf0303d273219db5d7eb4a2879ad977ed185 3], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ed7ed365172e27b0efe9d43cc962723c7193e34e 4], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7e63efef857575320fb413fbc3d0ee704b72845f 5)]

2.10. UIO

Click to read a [http://lwn.net/Articles/232575/ recommended LWN article about UIO]

UIO is a framework that allows to implement drivers in userspace. This kind of thing causes much noise due to "monolithic vs microkernel" topic. To the surprise of many, the Linux ecosystem has actually supported userspace drivers for cases that had sense for a long time. libusb allows to acces to the USB bus from userspace and implement drivers there. This is why you don't have specific drivers for, f.e., your scanner or USB digital camera, programs like sane, gphoto, gnokii, gtkam, hplip, or even some music players like rhythmbox or amarok, use libusb to access the USB bus and talk to USB devices directly. The 2D X.org drivers that you configure in your x.org file are another popular example of drivers that not only they run in userspace, they also are portable to other unix operative systems (they're also an example of why userspace drivers can't avoid hanging your machine due to a bug in the driver that triggers a hardware hang). CUPS and programs accesing the serial port like pppd are yet another example of userspace programs accessing the devices directly - the kernel doesn't implements any specific LPT printer or serial modem driver, those userspace programs implement the driver that knows how to talk to the printer.

In other words, userspace drivers are not new. UIO [http://lkml.org/lkml/2006/12/13/249 is not] a try to migrate all the Linux kernel drivers to userspace. In fact, a tiny (150 lines in the sample driver, including comments etc) kernel-side driver to handle some basic interrupt routine is need as part of every UIO driver. UIO is just a simple way to create very simple, non-performance critical drivers, which has probably been merged more with a "merge-and-see-if-it-happens-something-interesting" attitude than anything else. For now UIO doesn't allow to create nothing but very very simple drivers: No DMA, no network and block drivers....

UIO Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=beafc54c4e2fba24e1ca45cdb7f79d9aa83e3db1 (commit)] UIO Documentation: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e3e0a28b5b067d16b8e2e5ddaedecda5bd0c3ec2 (commit)] Sample kernel-side UIO Hilscher CIF card driver [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc4c4f45acbe1f1528d654b0b1793f25c175bf8f (commit)]

2.11. O_CLOEXEC file descriptor flag

Click to read a [http://lwn.net/Articles/232575/ recommended LWN article about the O_CLOEXEC open() flag]

In multi-threaded code (or more correctly: all code using clone() with CLONE_FILES) there's a race when exec'ing (see commit link for details). In some applications this can happen frequently. Take a web browser. One thread opens a file and another thread starts, say, an external PDF viewer. The result can even be a security issue if that open file descriptor refers to a sensitive file and the external program can somehow be tricked into using that descriptor. 2.6.23 includes the O_CLOEXEC ("close-on-exec") fd flag on open() and recvmsg() to avoid this problem.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f23513e8d96cf5e6cf8d2ff0cb5dd6bbc33995e4 (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a19542e5f694cd408a32c3d9dc593ba9366e2d7 2)]

2.12. Use splice in the sendfile() implementation

Splice is a innovative I/O method which was added in [http://kernelnewbies.org/Linux_2_6_17 Linux 2.6.17], based in a in-kernel buffer that the user has control over, where "splice()" moves data to/from the buffer from/to an arbitrary file descriptor with splice(), while "tee()" copies the data in one buffer to another, ie: it "duplicates" it, or vmsplice() to splice the data from/to user memory. Because the in-kernel buffer isn't really copied from one address space to another, it allows to move data from/to a fd without an extra copy (ie, "zero-copy").

For the particular case of sending the data from a file descriptor to a fd socket, there's been always the sendfile() syscall. splice() however is a generic mechanism, not just limited to what sendfile(). In other words, sendfile() is just a small subset of what splice can do, splice obsoletes it. In Linux 2.6.23, the sendfile() mechanism implementation is killed, but the API and its functionality is not removed, it's instead implemented internally with the splice() mechanisms.

Because sendfile() is critical for many programs, specially for static web servers and FTPs, performance regressions could happen (and performance improvements!) and the kernel hackers would really like to hear about them both in linux-kernel@vger.kernel.org and/or other usual communication channels.

In other news, 2.6.23 adds splice vmsplice-to-user support. It must be noticed again that splice() obsoletes sendfile() in linux, and its mechanisms allow to build further performance improvements in your software.

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5ffc4ef45b3b0a57872f631b4e4ceb8ace0d7496 (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0452a4e5d021900b07ebdeecb9ed03b49f164f3f 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ebf9909343392c929d9943c04f421cd42e03b530 3], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f0930fffa99e7fe0a0c4b6c7d9a244dc88288c27 4], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d054fe3d10cc1f9aec01378c38caa32dffdd0090 5], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d96e6e71647846e0dab097efd9b8bf3a3a556dca 6)]

2.13. XFS and EXT4 improvements

XFS
- Lazy Superblock Counters: When there are a couple of hundred transactions on the fly at once, they all typically modify the on disk superblock in some way. , locking the buffer until the transaction is committed into the incore log buffer. The result of this is that with enough transactions on the fly the incore superblock buffer becomes a bottleneck. In 2.6.23, XFS avoids this bottleneck (see commit for details). But due the way XFS works, in order to make it work well with this new feature, a new counter was added to track the number of blocks used by the free space btrees. This is an on-disk format change. As a result of this, lazy superblock counters are a mkfs option and at the moment on linux there is no way to convert an old filesystem, although one solution will be developed. Code [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=92821e2ba4ae26887223326fb0b95cdab963b768 (commit)]
- Concurrent Multi-File Data Streams: In media spaces, video is often stored in a frame-per-file format. When dealing with uncompressed realtime HD video streams in this format, it is crucial that files do not get fragmented and that multiple files a placed contiguously on disk. When multiple streams are being ingested and played out at the same time, it is critical that the filesystem does not cross the streams and interleave them together as this creates seek and readahead cache miss latency and prevents both ingest and playout from meeting frame rate targets. This feature creates a "stream of files" concept into the allocator to place all the data from a single stream contiguously on disk so that RAID array readahead can be used effectively. Each additional stream gets placed in different allocation groups within the filesystem, thereby ensuring that XFS doesn't cross any streams. Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2a82b8be8a8dacb48cb7371449a7a9daa558b4a8 (commit)]
EXT4: As it gets developed, ext4 codebase is synced periodically to mainline. In 2.6.23, a sync with some features has been done - this doesn't means that ext4 is stable:
- Fallocate() support [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a2df2a63407803a833f82e1fa6693826c8c9d584 (commit)], write support for preallocated blocks [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=56055d3ae4cc7fa6d2b10885f20269de8a989ed7 (commit)]
- Change on-disk format to support 2^15 uninitialized extents [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=749269facaf87f6e516c3af12763e03181b9c139 (commit)]
- Enable extents by default [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1e2462f93e011f63fd0f1fedd2c05338ca6b31c2 (commit)], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c29c0ae7f282828da3695167ed870131798348d9 (commit)]
- Add nanosecond timestamps [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef7f38359ea8b3e9c7f2cae9a4d4935f55ca9e80 (commit)]
- Remove 65000 subdirectory limit [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8628a14a27eb4512a1ede43de1d9db4d9f92bc3 (commit)]

2.14. Coredump filter mask

The purpose of this feature is to control which VMAs should be dumped based on their memory types and per-process flags, in order to avoid longtime system slowdown when a number of processes which share a huge shared memory are dumped at the same time, or just to avoid dumping information that you don't need. Users can access the per-process flags via /proc/<pid>/coredump_filter interface. coredump_filter represents a bitmask of memory types, and if a bit is set, VMAs of corresponding memory type are written into a core file when the process is dumped. The bitmask is inherited from the parent process when a process is created

Code: [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=76fdbb25f963de5dc1e308325f0578a2f92b1c2d (commit 1], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3cb4a0bb1e773e3c41800b33a3f7dab32bd06c64 2], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a1b59e802f846b6b0e057507386068fcc6dff442 3], [http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ee78b0a61f0514ffc3d59257fbe6863b43477829 4)]