Kernel 2.4 Hotfixes Willy Tarreau EXOSEC 1) Yet another kernel branch ? ------------------------------ These patches represent the most up-to-date fixes available for Linux Kernel 2.4. This kernel is currently maintained, but for stability reasons, several months now separe two consecutive releases. Some people might need to apply a few fixes to a stable kernel, but do not want to upgrade it to the latest -git or -pre release for stability reasons. The following patches will only be extracted from what will be included in a future release, so they should be a safe bet for people who need a stable and up-to-date kernel. Sometimes I might add a few build fixes which are not yet in official kernel as I discover problems while building the kernels. 2) How are they classified ? ---------------------------- All patch names start with 3 digits, the first one indicating a category, and the next ones a sequence number, to make it easier to apply them in a particular order. Patches are grouped into 6 categories : - security fixes => 1xx - critical bugfix => 2xx - major bugfix => 3xx - minor bugfix => 4xx - build fix => 5xx - documentation fixes => 6xx As much as possible, the patches will be independant. But if there are dependencies, then the last ones will depend on the first ones, so that the patches can still be incrementally applied. Since the 2.4 kernel is rather stable now, build fixes should be rather rare. Security fixes can happen anytime. Critical fixes should be quite rare too, as they would be caused by a major regression on an important feature, or an easily triggered panic. Major and minor bugfixes should be very rare, and should only be used for solving annoying cases when they "obviously" won't break anything. Major fixes generally fix problems such as oopses, memory leaks or anything which affects short-term system availability, while minor fixes are targetted at erroneous behaviour. Documentation fixes can happen at any time since they cannot break anything. The naming scheme is : -2.4.-patch-name-explaining-what-it-does- - X is the category digit, and YZ are 2 digits to preserve the order of the patches. They might be subject to changes, so they are not really part of the patch name (might be semi-automatically numbered). - 2.4.VV is the base kernel version. It will always be related to a release and never to a prerelease. - is the patch version. Sometimes a patch evolves, particularly when it touches security. It can also be used to allow a patch to coexist with a former which touches the same area. Example: 100-2.4.29-flash_erase-checks-cap_sys_admin-1 300-2.4.29-panic-when-backing-up-lvm-snapshots-1 301-2.4.29-oops-ata_to_sense_error-1 400-2.4.29-hiddev-eats-cpu-1 401-2.4.29-msf-overflow-multisession-dvd-1 402-2.4.29-lcd_ioctl-memory-leak-1 500-2.4.29-configure-mangles-hex-values-1 The patches should be applied in this order (although most of the time, they might be applied in any order). 3) Does someone test the patches ? ---------------------------------- I can compile and boot the patched kernels on the following architectures : - x86 (SMP:dual athlon, UP:pentium-m) - alpha ev6 UP - sparc64 UP/SMP However, I don't always have the time, nor can I always boot all machines. I generally use the patches in my personal patchset which I use about everywhere from workstations to servers to notebooks, and even on my company's servers. A file named "REPORT.TXT" will be provided with the patches. It will report what tests have been performed on the patched kernel : - not tested at all - does not build at all - fails to build some particular configurations only - builds with some additionnal patches - builds but not tested further - builds but does not work at all - builds and mostly works - builds and runs with some additionnal patches - builds and works without observable restrictions A column will include the tester's name to tell people whom to contact to get more information about the tests conditions. 4) How to rebuild the patches ? ------------------------------- The patches are provided in their raw original form in the "pool" directory. A valid kernel directory is needed only if you want to rebuild the complete merged patch. The kernel tree will not be touched, so it is safe to set it to the path of your reference tree. If you only want to rebuild the numbered split patches, then you don't need the kernel tree at all. When you run "make", a script will parse the "CONTENTS" file and determine the kernel version, and assign a sequence number to every patch. The resulting individual numbered patches will then lie in the "numbered" directory waiting for you to apply them in the same order, and a patch against your kernel will lie in the "merged" directory : # make clean # make Or you can build only the numbered patches if you want : # make numbered If you want to try the patches against a different kernel release, you can do it by specifying it in the KERNVER variable this way : # make KERNVER=2.4.28 And if you want to use a kernel directory other than /usr/src/linux-$KERNVER, you can pass it with the KERNDIR variable : # make KERNDIR=/usr/src/download/linux-2.4.29 A special patch will be automatically build into the "numbered" directory : 701-show-hotfix-level-in-extraversion This one will not have to be applied unless you want to make the hotfix level appear in your kernel version when you do a "uname -r". I would say that this is not recommended for people who want to apply additionnal patches, but it is recommended for people who want to run stable unpatched kernels in production and keep track of what is installed. Once the patches are rebuilt in the "numbered" directory, the "mkpatch" script automatically generates 2 patches into the "merged" directory : - one named 2.4.-.diff - one named 2.4.-.withver.diff The first one does not change the kernel version while the second one does. Pick the one you need. You can also rebuild the full patch yourself by applying them to your copy of the official kernel : # cd /usr/src # cp -al linux-2.4.29 linux-2.4.29-hf1 # cd !$ # /hotfix_dir/tools/apply /hotfix_dir/numbered/[1-6]* # /hotfix_dir/tools/apply /hotfix_dir/numbered/7* # if you want a version # cd .. # diff -urNX dontdiff linux-2.4.29{,-hf1} | gzip -9 > patch-2.4.29-hf1.gz # rm -rf linux-2.4.29-hf1 It is also recommended to build an incremental patch from previous hotfix : # interdiff -zq /2.4.31-hf4.withver.diff.gz \ merged/2.4.31-hf5.withver.diff \ > merged/2.4.31-hf4-hf5.diff When you're done, you can simply clean everything : # make clean 5) How to add/remove some patches ? ----------------------------------- The "make" process involves the "set-patch-names" script in the "tools" directory. This one uses the section numbers from the "CONTENTS" file to get the series number (1...6), and it uses a two-digit increment which starts at 01 to complement the sequence numbers, so that patches are applied in the exact same order as in the CONTENTS file. Only the lines beginning with a "+" alone are considered as patches. So you simply have to change this "+" to something else (eg: "#") to disable a patch. Or if you insert a line beginning with a "+" and followed by a file name, it will automatically add a numberred symbolic link into the "out" directory pointing to the referenced file in the "pool" directory. 6) Where to find updates ? -------------------------- Each patch in the "pool" directory has been carefully selected from the Git repository : git: http://rsync.kernel.org/pub/scm/linux/kernel/git/marcelo/linux-2.4.git web: http://kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git The -hf tree is updated everytime a significant update appears in the git repository. New hotfixes can be downloaded both as complete patch sets and as consolidated patches from EXOSEC's linux site : http://linux.exosec.net/kernel/2.4-hf/ -- Willy Tarreau - EXOSEC wtarreau at exosec.net