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. Grant Coady offered a great help in this area. He builds every version and runs them on his systems. It must take him a lot of time, so I sincerely thank him for this work. I must say that since he began to test them all, I've stopped doing more than building them. He puts his results online there : http://bugsplatter.mine.nu/test/linux-2.4/ 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, everything will be within "tmp/" 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", it will show you a help page indicating what you can do. To rebuild the patches, you need to run "make all" or "make patch". In this case, make will scan the "versions" directory to look for kernel versions for which it will rebuild a hotfix. A script will parse the "CONTENTS" file in each of these directories 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 located in "tmp/", waiting for you to apply them in the same order if you want to cherry-pick them, and a patch against your kernel will lie in the "merged" directory : # make clean # make all Or you can build only the numbered patches if you want : # make numbered Or you can build only a specific version by pointing the "SUBDIRS" variable to the directory hosting its "CONTENTS" file : # make patch SUBDIRS=versions/2.4.31 And if you want to use a kernel directory other than /usr/src/linux-$KERNVER, you can pass the base name via the KERNBASE variable, it will automatically be completed with the kernel version being processed. # make numbered KERNBASE=/usr/src/download/linux- 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 called from "versions/Makefile" 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 -purNX 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 You can rebuild the complete directory as it appears on the download address by simply making the "web" target : # make web Please note that in this case, the "split.tgz" archive will only be put into the most recent directory, because it is of no use in older kernels. Then, you can archive all the new directories at once in order to upload them to a web server : # (cd web; find * -not -type d | tar -T - -cf- ) | gzip -9 > all-vers.tgz When you're done, you can simply clean temporary files : # make clean Alternatively, you can clean everything : # make distclean 5) How to add/remove some patches ? ----------------------------------- The "make patch" 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 "+ " 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 "numbered" directory pointing to the referenced file in the "pool" directory. 6) How are new hotfixes built ? ------------------------------- This was the complicated part before the rewrite of the build process. Now, I just have to initiate the working directory and push new patches into the "incoming" directory : # make newrelease # cp /somedir/2.4.31-* incoming/ # make classify # vi sorted/*.lst => compact the descriptions by hand # make contents # make commit # make distclean When I need to initiate a hotfix for a new kernel release, I simply do : # cp -a versions/2.4.31 versions/2.4.32 # echo > versions/2.4.32/CHANGELOG # vi versions/2.4.32/CONTENTS => clean everything and make it "Hot Fix 0" # make contents commit SUBDIRS=versions/2.4.32 Note: it is best to create the new directory before actually working with the patches, it will avoid having to work on a specific version for this one. 7) 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 : hotfixes home : http://linux.exosec.net/kernel/2.4-hf/ last version : http://linux.exosec.net/kernel/2.4-hf/LATEST/LATEST/ RSS feed : http://linux.exosec.net/kernel/hf.xml build results : http://bugsplatter.mine.nu/test/linux-2.4/ (Grant's site) A mirror is available at home, but it's a small line, so please use it only if the primary site is unavailable : http://w.ods.org/kernel/2.4-hf/ -- Willy Tarreau - EXOSEC wtarreau at exosec.net