Linus Torvalds boccia due modifiche sul kernel Linux 7.1: perché sono inaccettabili

Il ciclo di sviluppo del kernel Linux non segue mai una linea piatta. Ogni finestra di integrazione del codice (merge window), cioè il periodo in cui vengono accettate e unificate le modifiche nel progetto, introduce miglioramenti e ottimizzazioni, ma anche problemi da risolvere (regressioni, ovvero errori che compaiono dopo cambiamenti) e discussioni tecniche tra gli sviluppatori su quale sia il modo migliore per far evolvere il codice. Con l’apertura della merge window per la versione 7.1, alcune proposte hanno attirato l’attenzione non tanto per ciò che promettevano, ma per la reazione diretta e piuttosto netta di Linus Torvalds. Due patch in particolare sono state respinte con motivazioni che vanno oltre il semplice merito tecnico: toccano principi architetturali e filosofia di sviluppo del kernel.

L’aumento costante del numero di core nelle CPU moderne ha reso visibili colli di bottiglia che anni fa erano trascurabili. Nei server dotati di decine o centinaia di core, l’elevato livello di attività simultanea mette sotto pressione alcune parti più datate del kernel Linux, soprattutto quelle progettate in un’epoca in cui il livello di concorrenza tra più operazioni era molto meno intenso. In questo scenario, ogni ottimizzazione deve però rispettare coerenza interna e manutenibilità: non basta migliorare le prestazioni, bisogna farlo nel modo giusto.

Perché Torvalds ha bloccato la patch sull’audit subsystem

La prima proposta di modifica, bocciata da Torvalds, nasceva per risolvere un problema concreto: su macchine con molti core, l’audit subsystem – il componente del kernel che registra le attività di sistema per motivi di sicurezza e tracciabilità – può rallentare operazioni comuni come l’apertura e la chiusura dei file.

Gli sviluppatori avevano individuato una causa tecnica precisa. Alcune funzioni interne, come get_fs_pwd(), recuperano continuamente informazioni sul percorso corrente dei processi. Ogni volta che questo accade, il kernel aggiorna un contatore interno legato alle dentry, cioè le strutture che rappresentano i file e le directory. Quando molti processi lavorano contemporaneamente nella stessa directory, queste operazioni creano contesa su uno spinlock, un tipo di blocco che protegge i dati condivisi ma che può diventare un collo di bottiglia sotto carico.

La soluzione proposta cercava di ridurre il numero di queste operazioni, introducendo funzioni di supporto per evitare passaggi ripetitivi. In pratica, meno aggiornamenti interni significano meno attese e quindi migliori prestazioni. Fin qui, nulla di controverso.

Il punto è che Torvalds ha guardato oltre il guadagno immediato. Secondo il “re pinguino”, la patch migliorava qualcosa che già era frutto di un comportamento incoerente: alcuni elementi del filesystem, come la directory corrente e quella di riferimento principale, sono trattati in modo diverso per ragioni storiche legate proprio all’audit subsystem, che non gestisce bene certi scenari come gli ambienti chroot – ovvero contesti isolati in cui un processo vede solo una parte del filesystem.

Torvalds ha giudicato l’approccio proposto come una scorciatoia: invece di sistemare il problema alla radice si concentra invece sulle prestazioni “cristallizzando” un difetto già presente. Il punto è che un difetto, se ottimizzato, tende a diventare permanente.

Da qui il rifiuto netto. Non perché la patch non funzioni, ma perché interviene nel punto sbagliato. Il messaggio di Torvalds è chiaro: prima si corregge il design, poi si pensa a renderlo più veloce; in caso contrario, si rischia di costruire su fondamenta fragili.

Perché Torvalds ha respinto la nuova opzione Kconfig

La seconda stroncatura di Torvalds riguarda Kconfig, il sistema che permette di scegliere quali funzionalità includere nel kernel durante la compilazione. L’idea era introdurre una nuova opzione, BOOTPARAM_RCU_STALL_PANIC, per attivare automaticamente un riavvio del sistema in caso di blocco legato a RCU.

RCU, acronimo di Read-Copy-Update, è un meccanismo interno che consente a più parti del kernel di leggere dati condivisi. Funziona molto bene, ma in rari casi può verificarsi uno “stallo”, cioè una situazione in cui la CPU non completa un’operazione nei tempi previsti. Quando accade, il sistema può restare in uno stato instabile.

Negli ambienti dove l’affidabilità è critica, come server o cluster, la scelta più sicura è spesso forzare un kernel panic, cioè interrompere il sistema e riavviarlo per tornare rapidamente operativi. La patch voleva rendere questo comportamento attivo di default già in fase di compilazione, senza dover configurare nulla dopo l’avvio.

La reazione dell’inventore del kernel Linux è stata anche in questo caso immediata e molto netta. Il problema, a suo avviso, non riguarda la funzionalità in sé, ma il modo in cui viene esposta. Aggiungere un’opzione in Kconfig significa complicare l’interfaccia che gli utenti vedono quando costruiscono il kernel.

Secondo Torvalds una funzione simile a quella proposta già esiste: su può attivare lo stesso comportamento tramite sysctl, cioè modificando un parametro del kernel a runtime, oppure passando un’opzione al momento del boot. In pratica, la patch non introduceva nulla di nuovo: spostava solo una configurazione già disponibile in un’altra fase.

Torvalds ha quindi interpretato la modifica come un’inutile duplicazione: la soluzione non è accumulare opzioni statiche, ma usare i meccanismi più flessibili già presenti.

Una lettura critica delle decisioni di Linus Torvalds

Le reazioni di Torvalds possono sembrare dure, ma seguono una logica ben precisa.

Il kernel Linux ha superato quota 30 milioni di linee di codice e continua a crescere; senza una disciplina rigorosa, la complessità diventerebbe ingestibile. Il rifiuto di patch apparentemente utili serve proprio a evitare derive difficili da correggere.

C’è anche un altro aspetto: la qualità del codice non si misura solo in benchmark. Un miglioramento del 5% o del 10% può non valere il costo di un design meno pulito, soprattutto quando si parla di componenti software centrali per i quali la prevedibilità del comportamento conta più della velocità pura.

Chi sviluppa patch per il kernel deve quindi tenere presente una regola non scritta: ogni modifica deve migliorare non solo ciò che tocca direttamente, ma anche il sistema nel suo insieme.