Linus elismerte, bugos sz@r került a 4.8-as kernelbe

Kernel

Linus a hétvégén (majdnem) menetrend szerint kiadta a végleges 4.8-as kernelt. Eleinte úgy tűnt, hogy ez is egy szokásos kiadás lesz, kedden azonban a főnök egy levelet írt az LKML-re, amelyben kifakadt. Sajnálatát fejezte ki amiatt, hogy közvetlenül a 4.8-as kernel kiadása előtt elfogadott és beolvasztott Andrew Mortontól egy patchsorozatot, mert az problémákat okoz és most már - benne egy bugos sz@rral - része a stabil kiadásnak:

I'm really sorry I applied that last series from Andrew just before doing the 4.8 release, because they cause problems, and now it is in 4.8 (and that buggy crap is marked for stable too).

A szóban forgó bugos sz@r nem más, mint egy patch, amely egy olyan hibát kísérelt meg javítani, ami a 3.15-ös kernel óta jelen van. Linus szerint azonban a javítás nem sikerült, sőt, szerinte a bugra készült patch sokkal rosszabb mint az eredeti bug maga, mert az sosem nyírta ki a gépét:

The bug that commit 22f2ac51b6d64 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") purports to have fixed has apparently been there since 3.15, but the fix is clearly worse than the bug it tried to fix, since that original bug has never killed my machine!

Linus kérte Mortont, hogy ne fogadjon el többé ilyen patcheket, hiszen már korábban is volt kirohanása a BUG_ON() debuggolási célú felhasználása ellen. Emellett belinkelte egy 2002-es levelét, amelyben a BUG_ON() helyes használatát ecsetelte:

I suspect I will have to finally just remove the idiotic BUG_ON() concept once and for all, because there is NO F*CKING EXCUSE to knowingly kill the kernel. [...]

And dammit, if anybody else feels that they had done "debugging messages with BUG_ON()", I would suggest you

(a) rethink your approach to programming

(b) send me patches to remove the crap entirely, or make them real *DEBUGGING* messages, not "kill the whole machine" messages.

I've ranted against people using BUG_ON() for debugging in the past. Why the f*ck does this still happen? And Andrew - please stop taking those kinds of patches! Lookie here:

https://lwn.net/Articles/13183/

so excuse me for being upset that people still do this shit almost 15 years later.

A szál itt kezdődik.

( uid_16313 | 2016. 10. 06., cs – 10:03 )

Ezt nevezhetnénk a QM csödjének is, persze egyszerübb azt b@sztatni, aki elkövette a hibát.

--
robyboy

Andrew Morton a minőségellenőr. A 2.6 óta ő a Karbantartó, én nem tudom, hogy ez változott volna. Neki kell begyűjtenie a patcheket, ő ellenőrzi a minőségüket és ő engedi át Linus felé azt, ami már szerinte megfelel. Linus csak begyűjti az alrendszerek karbantartóitól a patchkészleteket, amikor azok egy pull request-et küldenek neki.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?…

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reported-by: Antonio SJ Musumeci <trapexit@spawn.link>
Debugged-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org> [3.15+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

--
trey @ gépház

Milliárdokba kerülő kritikus üzleti folyamatokat ki tesz mindig latest stable kernelre? Egész pontosan kettő napja jelent meg a hibás patchet tartalmazó kernel.

Ha egy kritikus üzleti folyamat Linux alatt megy, akkor az RHEL vagy SUSe. Amiknél >1 éve kinn van a kernel, amikor kijönnek.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ja, viszont a 14 éves bug nagy valószínűséggel azért van ott, mert még senki nem találkozott vele... az üzleti kritikus cuccokat futtatóknak meg azért van support szerződése, hogy ha mégis belefutnának, szólnak az RH-nak/Novellnek, akik így, vagy úgy, kijavítják.

Egyébként meg mutass bármit, amiben nincs bug (legyen az akár HW, akár SW).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A két szmájli miatt nem tudtam eldönteni, hogy ironizált-e vagy sem, valami hasonlót írtam volna én is (meg hogy ráadásul nem kizárólagosan ő fut a kernel felett, úgyhogy kölcsönhatások is vannak)...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

ha ennyire problémás neki (legyen az morton vagy torvalds) a BUG_ON, akkor csak rá kell keresnie a pull requestekben, hogy van-e bennük és ha van, akkor visszadobja vagy jobban ránéz. mert néztem és "+ BUG_ON" sorból van egy pár.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( szegecs | 2016. 10. 06., cs – 13:39 )

"buggy crap is marked for stable"

Linux, dióhéjban.

( medve540 | 2016. 10. 06., cs – 13:51 )

Valaki, aki ismeri a kernel fejlesztés folyamatát elmesélhetné hogyan zajlik a tesztelés, mert érdekelne.

Nekem az tűnne logikusnak, hogy legyen egy virtuális gép, vagy inkább virtuális hardver definíció, amit az igazi specifikációja alapján készítenek el. Utána lehetne írni unit és funkcionális teszteket, amik a lefordított kernelt ezen a virtuális gépen futtatva végrehajtanák a teszteseteket és jelentenék, ha valami nem működne.
De nyilván nem ez a helyzet, mert a kernel kódját nézve nem találtam teszteket. Szóval gondolom valós hardverrel fejlesztik, ami nem kis bravúr.

Eventually, Linus decided that because the vast majority of users ran distribution kernels, the distribution maintainers should handle the stabilization process. The official tree, although not completely ignoring the need for stabilization, would not prioritize it over active development.

--
trey @ gépház

Picit szomorú vagyok, hogyha tényleg csak ennyi.
Ennek ellenére, illetve a széles hardver támogatás mellett, elég stabil.
Bár tray idézete alapján a disztribúció készítőknek kell megköszönni az alapos tesztelést meg javítást. Ezt támasztja alá az is, hogy az Android kernel elég instabil. Próbálgattam jó pár ROM-ot az elmúlt hetekben és valami mindegyikben szar volt (kamera lefagy, vagy újraindul az OS, vagy sleep of death). Gondolom a telefon gyártók azért adják ki olyan lassan az AOSP kiadás után a saját verziójukat, mert egy csomó hardver specifikus javítást bele kell rakniuk, mire stabil lesz.

( evone | 2016. 10. 07., p – 11:39 )

"a linuxon röhög a fél világ" :DDD

( oykawa | 2016. 10. 08., szo – 14:33 )

Valami nem kerek az I915 driverrel, 10 másodpercenkénet hibát ír: "[drm:hsw_write_dcomp] *ERROR* Failed to write to D_COMP"
vga: 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
Maga a gép egy Dell Poweredge T20 Debian 8-al, eddig hála Istennek ilyen gondom nem volt, 4.7.6-al tökéletes!

Most néztem 4.8.1-el is ugyanaz... 4.7.7 szintén jó!

Oykawa

Jelentsd regresszióként.

Amúgy izgalmasak Intel-ék, mert mikor úgy tűnik, hogy nem érdekli őket igazán a bugreport, a következő kiadásra fixed állapotba kerül a hiba és tényleg javítva lesz. Szóval nem erősségük a kommunikáció, de nekem volt egy kínos i915-ös hibám, melyet javítottak.