Linux kernel 6.19: le novità che contano per driver, prestazioni e supporto hardware

Linux 6.19 arriva in un punto del calendario in cui molte aziende stanno già pianificando Q2 e Q3. Questo kernel non è una release “di facciata”: porta nuove interfacce e nuove capacità che prima o poi finiscono in backport, in kernel di distribuzione e in appliance. Anche se oggi non lo metti su produzione, ti conviene sapere cosa sta entrando nell’ecosistema perché i vendor lo tireranno dentro a ondate.

C’è un altro dettaglio che cambia il modo in cui leggere 6.19: è l’ultimo numero prima del passaggio a 7.0. Non significa “rivoluzione obbligatoria” ma ci dice che la finestra di merge ha assorbito cambiamenti trasversali. Questo spiega perché troviamo insieme listns(2), Live Update Orchestrator, ottimizzazioni di I/O e networking e un pacchetto di enablement hardware che tocca sia workstation sia datacenter.

Abbiamo filtrato l’enorme volume di commit e ci siamo concentrati sulle patch che spostano scelte architetturali, runbook e budget di CPU. Il risultato è un quadro che parla a chi amministra sistemi: cosa cambia, perché cambia e dove può mordere.

Sommario dei contenuti

• Baseline consigliata: 6.19.2 e la lezione di 6.19.1
• Driver e supporto hardware: cosa si muove davvero
• Prestazioni core: CPU, NUMA e profiling meno invasivo
• Networking: TX fino a 4x e nuovi sysctl da conoscere
• Storage e filesystem: ext4 a blocchi grandi, Btrfs e zram
• Container e osservabilità: listns(2), BPF e tracing
• Virtualizzazione e reboot gestiti: Live Update Orchestrator
• Sicurezza: PCIe Link Encryption, LASS e hardening pratico
• Cosa testare prima dell’upgrade

Baseline consigliata: 6.19.2 e la lezione di 6.19.1

Chi gestisce produzione lo sa ma ogni tanto serve ribadirlo: i point release iniziali non sono “cerotti minori”. In questo caso 6.19.2 non è una rifinitura, è la baseline sensata. In 6.19.1 è entrata una modifica nel driver core legata al locking su driver_match_device e in alcune combinazioni di driver la conseguenza concreta è stata la peggiore possibile: boot che non arriva al login.

La correzione è arrivata in fretta perché il problema era riproducibile e ad alta severità. Il nostro consiglio operativo è semplice: se state installando dai repository verificate che il pacchetto sia almeno 6.19.2, se compilate in house partite dal tag 6.19.2 e se avete un parco con moduli fuori albero testate su macchine “difficili” prima di toccare il resto.

Driver e supporto hardware: cosa si muove davvero

In 6.19 c’è un pezzo di storia grafica che cambia direzione. Le GPU AMD GCN 1.0 e 1.1 passano a usare di default AMDGPU al posto del driver Radeon legacy. Per noi il punto non è “gaming” in astratto, è che questa scelta rende più lineare l’accesso allo stack moderno e riduce la quantità di workaround che ancora troviamo in ambienti misti. Se vi serve controllare il comportamento su SI o CIK, le opzioni modulo restano uno strumento concreto e i parametri classici (si_support e cik_support) tornano utili anche solo per isolare regressioni.

Sul fronte display entra una base tecnica che fin qui era frammentata: la DRM Color Pipeline API mette ordine nelle trasformazioni colore pre blending e post blending dentro l’hardware dei display controller. Tradotto in impatto: HDR gestito in modo più coerente e spazio per applicazioni color managed che oggi devono compensare con workaround in user space. In parallelo arriva anche una proprietà di sharpness per il filtro CASF su Intel e questo è un segnale di maturità: la pipeline colore non è più solo “output”, diventa una parte esplicita del driver model.

Su piattaforme e server, 6.19 non si limita a “aggiungere ID”. Da un lato continuiamo a vedere enablement Intel su Wildcat Lake e Nova Lake, con prime basi anche per Xe3P su iGPU Nova Lake e per hardware dedicato come Crescent Island. Dall’altro lato emergono due punti che parlano direttamente ai team infrastruttura: KVM su AMD SVM guadagna x2AVIC fino a 4096 vCPU e il codice di locking di TDX viene ritoccato per togliere condizioni di race che su hypervisor diventano bug intermittenti, quindi costosi da inseguire.

Se lavorate su embedded o su infrastrutture eterogenee, vale la pena segnarsi anche questi movimenti: MPAM su Arm entra upstream per un controllo risorse più simile a RDT, parte l’enablement LoongArch32 come port a 32 bit, RISC-V introduce hot plug parallelo dei core e compaiono nuove basi per SoC come Tenstorrent Blackhole e Black Sesame C1200. Non sono feature da “desktop” ma sono mattoni che spesso decidono se un prodotto resta fuori mainline o ci entra.

Infine, un dettaglio da power user che però incide anche in azienda: arriva un driver ASUS Armoury e supporto per laptop Uniwill, insieme a miglioramenti continui per Apple Silicon. Sembrano note marginali ma hanno un effetto concreto: meno patch private, meno kernel custom e più possibilità di standardizzare immagini e provisioning su macchine che oggi fanno eccezione.

Prestazioni core: CPU, NUMA e profiling meno invasivo

Se guardiamo 6.19 con gli occhiali di chi misura, emergono tre aree. La prima è “CPU core e scheduling” e qui c’è un segnale tecnico preciso: l’overhaul di rseq e della gestione dei CID. rseq è un pezzo sottile ma decisivo per performance su user space che fa uso intenso di per CPU data e quando viene rivisto di solito è perché qualcuno ha trovato costi nascosti su carichi moderni. L’impatto tipico lo vedono runtime, allocator e software che macina thread.

La seconda area è il tuning su macchine grandi. 6.19 espone in sysfs i housekeeping CPU con un percorso canonico che strumenti di performance tuning possono finalmente usare senza euristiche fragili. Se state isolando core per latenza (isolcpus, nohz_full, rcu_nocbs) questo dettaglio riduce errori di configurazione e soprattutto rende più affidabile l’automazione.

La terza area è il profiling. Con il supporto SFrame il kernel può fare stack unwinding veloce per strumenti come perf senza imporre frame pointer come compromesso universale. SFrame nasce per contenere il minimo informativo utile a tracciare stack in modo rapido, sta già dentro GCC e in prospettiva apre una strada per diagnosticare in produzione con overhead più controllato.

Nel pacchetto performance c’è anche hardening “che non costa troppo”. Lo scoped user access mira a ridurre l’uso delle barriere di speculazione quando non servono quindi a togliere quel peso che su workload intensivi si accumula. In parallelo compaiono ottimizzazioni AES-GCM che favoriscono Zen 3 e CPU AVX-512 ed è un promemoria: crypto e performance non sono più mondi separati per chi fa storage cifrato o TLS massivo.

Un numero che vale la pena tenere a mente se avete audit pesante: nelle patch di 6.19 troviamo una riduzione dichiarata intorno al 50% dell’overhead audit. Non è marketing, è il tipo di miglioramento che può cambiare l’equilibrio tra compliance e throughput, soprattutto nei sistemi dove auditd è sempre acceso e non “solo per incident response”.

Networking: TX fino a 4x e nuovi sysctl da conoscere

Questo è uno dei punti più concreti di 6.19. Nel layer di TX queuing arriva una lista lockless che ottimizza throughput ed efficienza. Il dato dichiarato nelle patch è duro: in workload TX pesanti si parla di un miglioramento del 300%, quindi fino a 4x. La stessa nota tecnica aggiunge due dettagli che fanno capire la portata: invio di circa il doppio dei pacchetti al secondo con circa metà cicli CPU.

Non è il tipo di patch che “fa bene a tutti” nello stesso modo. Se il vostro collo di bottiglia è altrove non vedrete magia. Se invece siete su router software, load balancer, storage distribuito con traffico est-ovest o su cluster che fa TLS termination su NIC veloci, questa è una modifica che merita un test mirato. La raccomandazione pratica è costruire un test TX realistico con burst, queue discipline e CPU pinning simili alla produzione.

In 6.19 compaiono anche strumenti di controllo che contano più di quanto sembrino. Viene introdotto un sysctl per permettere a flussi costantemente busy di migrare verso CPU e NIC queue più adatte, anche quando non entrano mai in idle. È una scelta che può aumentare efficienza ma porta con sé un rischio esplicito: riordino pacchetti. Va capito in base al vostro traffico, al vostro stack e alla vostra tolleranza al jitter.

Altri dettagli utili per chi fa tuning: nuovi sysctl TCP per gestire inflazione del receive buffer in base a RTT basso e percentuale di SRTT per la compressed SACK. In più entra net.core.qdisc_max_burst per controllare quanti pacchetti possono essere accumulati prima della qdisc. Nessuno di questi è “obbligatorio” ma sono leve che possono fare la differenza quando state spremendo line rate.

Infine, un punto spesso ignorato finché non arriva un incidente: l’accounting memoria per protocollo. 6.19 introduce la possibilità di opt out dal global per protocol memory accounting se un socket viene configurato via sysctl o da un programma BPF. È una funzione potente per casi particolari ma va gestita con disciplina, perché aggirare accounting globale è un modo facile per trasformare un nodo in un laboratorio di OOM.

Storage e filesystem: ext4 a blocchi grandi, Btrfs e zram

ext4 in 6.19 guadagna un’abilità che sembrava “vietata” da sempre: block size più grande della page size della macchina. Su x86 con page da 4 KB significa poter creare ext4 con blocchi più grandi. Il benchmark riportato nelle patch parla di un miglioramento medio intorno al 50% sulle scritture buffered. La stessa nota aggiunge un caveat che dobbiamo tenere a mente: direct I/O può degradare perché cresce il tempo speso per checksum.

Questo è un esempio perfetto di novità che va letta con disciplina. Il kernel da solo non trasforma un ext4 esistente. Il beneficio arriva se decidete di creare filesystem con block size maggiore e se i vostri workload sono davvero dominati da buffered writes. Su storage che vive di direct I/O o su database con profili particolari, il trade off va misurato e non dato per scontato.

Sempre in ext4, 6.19 migliora in modo marcato throughput della deframmentazione online. Anche qui il valore pratico emerge in ambienti che scrivono tanto e frammentano nel tempo, quindi non solo laptop. Pensate a storage log heavy, VM image che crescono, workload che fanno append e rewrite.

Btrfs riceve una serie di interventi che chi usa il filesystem in produzione capisce al volo. Scrub e device replacement non bloccano più i tentativi di sospensione perché lo scrub registra lo stato e riprende mentre device replacement richiede un restart dal principio. Entra anche supporto per shutdown ioctl e migliorano le basi (ancora sperimentali) per block size oltre la page in RAID56. In parallelo ci sono preparazioni per fscrypt e ottimizzazioni di locking quando il filesystem processa ticket di reservation.

Se lavorate con swap compressa, 6.19 porta un miglioramento concreto su zram: writeback bio batching. È un dettaglio tecnico ma utile perché riduce overhead quando zram scarica su un backing device, quindi limita la penalità nei momenti di pressione memoria in cui ogni millisecondo conta.

Nel block layer entra un’aggiunta che interessa chi fa cluster e storage condiviso: nuovi ioctl per leggere chiavi di persistent reservation e lo stato corrente di reservation su un block device. In pratica, strumenti e cluster manager possono ispezionare PR state in modo più diretto. È il tipo di funzione che non fa rumore in un changelog generico ma cambia un runbook quando serve.

Un ultimo punto di storage che vale citare per chi fa file server: NFS può disabilitare la cache dei dati scritti in direct I/O. È una scelta utile in scenari in cui direct I/O viene usato per bypassare page cache e la cache involontaria diventa un costo. Non è una patch che attivi “a prescindere” ma è una leva in più per lavorare su latenza e memoria.

Container e osservabilità: listns(2), BPF e tracing

listns(2) è la novità che fa capire che in 6.19 si sta lavorando sul kernel “da infrastruttura”. Oggi, per enumerare namespace attivi, molti strumenti finiscono a scansionare /proc/<pid>/ns su ogni processo. Funziona ma scala male, soprattutto su nodi densi e su ambienti dove i namespace sono creati in modi diversi. listns(2) introduce un percorso diretto: iterazione con paginazione e filtri per tipo di namespace.

Il dettaglio interessante non è solo la syscall. Sotto c’è un intervento sul lifecycle: viene distinta la vita del namespace dalla sua visibilità per user space. Questo chiude un comportamento indesiderato in cui un namespace poteva essere “riaperto” attraverso file handle anche quando stava scomparendo dal punto di vista dell’utente. Qui c’è impatto sicurezza e c’è impatto operativo, perché tool e audit smettono di inseguire oggetti fantasma.

Nel mondo BPF continuano a entrare pezzi che allargano i confini del possibile senza passare dal kernel module. In 6.19 vediamo nuovi mattoni per rendere più flessibili i programmi (indirect jumps su set map), più strumenti per lavorare con dynptr legati ai file e un’attenzione continua a integrazione con networking e accounting. Se state già usando BPF come “collante” tra policy e telemetria, questo è il tipo di release che vi interessa.

Sul fronte osservabilità, oltre a SFrame, 6.19 spinge su perf con un output JSON più coerente per eventi e metriche e su tracing con la possibilità per gli eventi di syscall di leggere buffer da user space. Sono dettagli che diventano grandi quando dovete investigare senza toccare troppo il sistema. È qui che si vede il salto: meno strumenti “intrusivi” e più diagnostica integrata nel kernel in modo sostenibile.

Virtualizzazione e reboot gestiti: Live Update Orchestrator

Live Update Orchestrator è una delle novità più interessanti per chi gestisce cloud e piattaforme. L’idea è rendere strutturato il percorso di kexec handover con una state machine e una uAPI dedicata esposta tramite /dev/liveupdate. Non è un “pulsante magico” ma è un modo per trasformare un reboot in un passaggio controllabile, con meccanismi per preparare lo stato, congelare processi e riallineare dopo l’update.

Il dettaglio tecnico che ci interessa è la conseguenza operativa. L’orchestratore prevede un flusso con stati (normal, prepared, frozen, updated) e ioctls che guidano prepare, freeze, unfreeze e l’update vero e proprio. In mezzo c’è un tema delicato: come preservare stato user space attraverso un reboot. Il design usa memfd come contenitore preservabile ma introduce limiti precisi: non potete ridimensionare memfd nella finestra prepared e alcuni attributi come close-on-exec e file seals non vengono preservati. È un compromesso esplicito che va capito prima di pensare a integrazioni.

Per chi fa virtualizzazione, 6.19 continua a spingere su scalabilità e sicurezza. Oltre a x2AVIC su AMD SVM per arrivare a 4096 vCPU, vediamo interventi su TDX locking e lavori intorno a guest_memfd con policy NUMA. Sono componenti che non fanno notizia generalista ma sono l’ossatura di ambienti con VM grandi e con obiettivi di isolamento sempre più aggressivi.

Sicurezza: PCIe Link Encryption, LASS e hardening pratico

6.19 introduce infrastruttura per PCIe Link Encryption e autenticazione del device. Il punto pratico è la direzione: protezione più forte sul percorso I/O in scenari dove l’attaccante non è “solo un processo” ma può essere un componente sulla catena hardware. È lo stesso mondo in cui stiamo vedendo crescere confidential computing e progetti che spingono Trusted I/O. Il kernel qui fornisce plumbing, poi servirà hardware e firmware compatibile per renderlo operativo.

Sul lato CPU, Intel LASS entra in mainline come base per separazione dello spazio di indirizzamento lineare. È un tassello che non si traduce in una checkbox immediata per l’utente ma va letto come investimento su isolamento memory side. In parallelo, lo scoped user access lavora per ridurre il costo delle barriere di speculazione quando non sono necessarie, quindi con un occhio doppio: sicurezza e performance.

Il pacchetto hardening include anche dettagli “da operatore”: migliora la granularità del labeling SELinux per i file memfd, cambia la performance della lookup AVC con una strategia hash diversa e si lavora sul lato audit per ridurre overhead. Se avete policy SELinux severe e audit sempre attivo, questi interventi possono cambiare il profilo di costo del controllo.

Infine, crypto. 6.19 aggiunge SHA-3 e BLAKE2b nella libreria crittografica del kernel. Non è una notizia da homepage, è un dettaglio che diventa concreto quando fate integrity checking, storage cifrato o sistemi che devono essere pronti a policy più aggiornate lato compliance.

Cosa testare prima dell’upgrade

Se dobbiamo trasformare 6.19 in una checklist, noi la scriviamo così. Non è “come installare un kernel”, è come ridurre sorprese in produzione.

Checklist minima per sysadmin

• Versione: assicurati che i nodi test siano su 6.19.2.
• Boot path: prova sistemi con initrd complessi, storage particolare e driver fuori albero.
• Networking: misura TX sotto carico reale, valida eventuali sysctl nuovi che usi per tuning.
• Filesystem: se valuti ext4 a blocchi grandi, separa benchmark buffered da direct I/O e misura checksum cost.
• Osservabilità: verifica che profiling e tracing non aumentino overhead rispetto alla baseline precedente.
• Rollback: tieni kernel precedente installato e una procedura di ritorno che non richieda improvvisazione.

La cosa che ci ha colpito di 6.19 non è una singola feature, è la direzione. Si vede che il kernel sta spostando energia su tre fronti: osservabilità dei container senza hack, reboot gestiti per ridurre downtime e I/O che scala meglio quando il collo di bottiglia è CPU.

Il rischio vero, oggi, non è adottare 6.19. Il rischio è adottarlo con la mentalità sbagliata, come se fosse solo “un kernel più recente”. Qui ci sono cambiamenti che chiedono metodo: partire da 6.19.2, misurare sul reale, tenere un fallback e non innamorarsi del numero.

Se dovessimo scegliere un singolo indicatore di maturità, prenderemmo listns(2). Non perché tutti lo useranno domani, perché mette fine a una zona grigia dove user space si arrangiava male. Quando un kernel inizia a eliminare workaround storici, vuol dire che sta preparando il terreno per la prossima ondata di tooling.

A cura di Junior Cristarella.