kernel patchen

[torben]

Hallo,

ich habe folgendes Problem. Ich will meinen Kernel auf 2.4.21 upgraden soweit sogut. Gleich beim Upgraden möchte ich auch noch die Patches Preemptible, Low latency, Variable Hz und GrSecurity einspielen (die Links finden sich unten). Die ersten drei Patches kann ich noch ohne Probleme einspielen jedoch sobald ich den GrSecurity Patch einspielen will bekomme ich folgende Meldung:

Code: Select all

Hunk #1 FAILED at 400.
1 out of 1 hunk FAILED -- saving rejects to file drivers/char/mem.c.rej
Hunk #2 FAILED at 1073.
Hunk #3 succeeded at 1378 (offset 227 lines).
1 out of 3 hunks FAILED -- saving rejects to file mm/mmap.c.rej
patching file mm/mremap.c

Dabei ist die Reihenfolge egal. Beim Testen ist mir aufgefallen, dass sich anscheinend die Patches Hz, Lowlatency und GRSecurity überschneiden, sprich wenn ich GRsecurity patche kann ich preempt ohne Probleme hinzufügen erst bei Hz und Latency mekert er.
Kommen diese Fehler dadurch, dass eine Datei zwei mal gepatcht wird und somit nicht weiter schlimm ist?

Gruss Torben

---
Hier die Patches:
http://www.grsecurity.net/grsecurity-1. ... 4.21.patch

http://www.zip.com.au/~akpm/linux/2.4.2 ... y.patch.gz

http://members.optusnet.com.au/ckolivas ... 21-ck2.bz2

http://www.kernel.org/pub/linux/kernel/ ... 21-1.patch

[captaincrunch]

Kommen diese Fehler dadurch, dass eine Datei zwei mal gepatcht wird und somit nicht weiter schlimm ist?

Erster Teil : ja. Zwei Patche versuchen das gleiche File (mmap.c) zu patchen, wobei sich die Patche aber gegenseitig aushebeln.

"Schlimm" ist das nicht zwangsläufig, da der zweite Patch nichts an dem File ändert (wie die Fehlermeldung ja schon vermuten lässt). In den meisten Fällen bricht das kompilieren aber aufgrund dessen mittendrin ab, weil ein Teil nicht mehr zum anderen passt.
Einzige Möglichkeit, das zu ändern wäre, selbst in den Sourcen rumzupfuschen, oder auf (mindestens) einen Patch zu verzichten (näheres dazu im nächsten Absatz).

Mal was ganz anderes :
- GRSecurity -> OK
- Low-Latency auf einem Server ? Wozu ? Gameserver ?
- Dazu noch vHertz und preemtible ? Warum nimmst du dann nicht gleich das gesamte ck-Patchset ?

Sorry, aber alles zusammen halte ich für ziemlich sinnbefreit, vor allem, weil das den Kernel vielleicht "superschnell", dafür aber auch teilweise verdammt instabil werden lässt. An dieser Stelle sag ich's gerne noch einmal : sofern ich nicht Benchmarks sehe, die ich nicht selbst gefälscht habe ;) , halte ich sämtliche "machmichschneller"-Patche für sinnfrei, und vertraue eher darauf, den Kernel mal vernünftig abzuspecken (wie bei den (inoffiziellen) Debianhowto-Kerneln passiert).
Aber es ist ja schließlich deine Kiste ... ;)

[torben]

Hi CaptainCrunch,

vorab das hast du richtig erkannt. Es handelt sich um einen Server den ich mir zusammengekauft habe und in ein Rechenzentrum stellen werde. Darauf werden dann Gameserver laufen, aber nicht im gewerblichen Bereich. Welche von diese Patches kannst du denn empfehlen und/oder kennst du eventuell noch andere gute patches?

Das Kernel "abspecken" geschieht bei mir in der Config, indem ich einfach alles deaktiviere was ich nicht brauche (USB, SCSI, ...).

Gruss Torben

[captaincrunch]

Welche von diese Patches kannst du denn empfehlen und/oder kennst du eventuell noch andere gute patches?

Es kommt dabei ganz darauf an, wo deine Prioritäten liegen : wenn du Wert auf Sicherheit legst, kann ich dir den GRSecurity nur allerwärmstens an Herz legen.

Sofern du den Kernel "tunen" willst, schau dir mal das o.g. ck-Patchset ( http://members.optusnet.com.au/ckolivas/kernel/ ) an, wobei ich den Sinn dabei eher auf Desktop-Kisten sehe.

Beides gemischt wird eine relativ heikle Sache, da sowohl GRSecurity, als auch sämtliche "performancesteigernden" Patches in der Viertual Memory (VM) des Kernels rumfuhrwerken, und sich daher wohl fast zwangsläufig ins Gehege kommen werden, wobei ich da den vHertz-Patch noch als das geringste Ã?bel ansehen würde (vor allem meine ich, hier im Gameserver-Forum schon gelesen zu haben, dass der mit dem GRSecurity zusammen funktioniert).

Was mich persönlich aber am allermeisten interessieren würde : probier doch einfach mal verschiedene Patches durch, und miss die Zeit, die dann ein Kernelcompile braucht (irgendein generischer, damit gleiche Voraussetungen bestehen), am besten per time make dep clean bzImage . Ich behaupte, dass der Unterschied nicht wirklich gravierend sein wird.

[dopefish]

low latency und preemtive patches machen bei einen spielserver sowohl subjektiv im spiel wie auch objektiv bei statistische auswertungen schon einen merkbaren unterschied.

[captaincrunch]

Ich sage ja : ich glaube nur den Statistiken (Benchmarks), die ich selbst gefälscht habe ;)

Torben wird halt wie gesagt entweder Prioritäten setzen müssen, oder ganz fix so fit in der Kernelprogrammierung werden müssen, dass er die Patche in Eigenregie anpassen kann ... ;)

[dopefish]

*hehe* los Torben bastele 'nen netten patch mit alles drin *anfeuer*