A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.
An experimental new design for Linux’s virtual memory system would turn a large amount of system RAM into a fast RAM disk with automatic sync to magnetic media. Most servers comes with 2-16 GB ram installed but not with a terabyte of installed memory (for 1TB+ ram go with IBM / Sun E25k server line). There is a new kernel patch called Ramback:
Ramback is a new virtual device with the ability to back a ramdisk by a real disk, obtaining the performance level of a ramdisk but with the data durability of a hard disk. To work this magic, ramback needs a little help from a UPS. In a typical test, ramback reduced a 25 second file operation to under one second including sync. Even greater gains are possible for seek-intensive applications. The difference between ramback and an ordinary ramdisk is: when the machine powers down the data does not vanish because it is continuously saved to backing store. When line power returns, the backing store repopulates the ramdisk while allowing application io to proceed concurrently. Once fully populated, a little green light winks on and file operations once again run at ramdisk speed.
However, this solution depends upon UPS:
If line power goes out while ramback is running, the UPS kicks in and a power management script switches the driver from writeback to writethrough mode. Ramback proceeds to save all remaining dirty data while forcing each new application write through to backing store immediately.
Yesterday, I wrote about a serious Linux kernel bug and fix. However, few readers like to know about patching running Linux kernel. Patching production kernel is a risky business. Following procedure will help you to fix the problem.
Step # 1: Make sure your product is affected
First find out if your product is affected by reported exploit. For example, vmsplice() but only affects RHEL 5.x but RHEL 4.x,3.x, and 2.1.x are not affected at all. You can always obtain this information by visiting vendors bug reporting system called bugzilla. Also make sure bug affects your architectures. For example, a bug may only affect 64 bit or 32 bit platform.
Step # 2: Apply patch
You better apply and test patch in a test environment. Please note that some vendors such as Redhat and Suse modifies or backports kernel. So it is good idea to apply patch to their kernel source code tree. Otherwise you can always grab and apply patch to latest kernel version.
Step # 3: How do I apply kernel patch?
These instructions require having the skills of a sysadmin. Personally, I avoid recompiling any kernel unless absolutely necessary. Most our production boxes (over 1400+) are powered by mix of RHEL 4 and 5. Wrong kernel option can disable hardware or may not boot system at all. If you don’t understand the internal kernel dependencies don’t try this on a production box.
Change directory to your kernel source code:
# cd linux-2.6.xx.yy
Download and save patch file as fix.vmsplice.exploit.patch:
# cat fix.vmsplice.exploit.patch
@@ -1234,7 +1234,7 @@ static int get_iovec_page_array(const struct iovec __user *iov,
error = -EFAULT;
- if (unlikely(!base))
+ if (!access_ok(VERIFY_READ, base, len))
Now apply patch using patch command, enter:
# patch < fix.vmsplice.exploit.patch -p1
Now recompile and install Linux kernel.
I hope this quick and dirty guide will save someones time. On a related note Erek has unofficial patched RPMs for CentOS / RHEL distros.