Linux kernel 7.1: novità per i server VPS

Novità del kernel Linux 7.1

Il kernel Linux 7.1 è stato rilasciato il 14 giugno 2026, nove settimane dopo la versione 7.0. Per chi utilizza un VPS (virtual private server), le modifiche rilevanti rientrano in quattro aree: storage e filesystem, networking, gestione della memoria e controllo dei processi e dei container. Il resto della release riguarda soprattutto desktop e grafica, componenti che un server headless non carica.

Prima, però, serve una seconda risposta. Sul tuo server 7.1 quasi certamente non è in esecuzione e non lo sarà ancora per molto tempo. kernel.org non indica 7.1 come release longterm. All'11 agosto 2026 le linee longterm sono 6.18, 6.12, 6.6, 6.1, 5.15 e 5.10; tutte le principali distribuzioni server si basano su una di queste linee oppure su una linea mantenuta direttamente dalla distribuzione. La "novità nel kernel" e la "novità sul tuo server" possono essere distanti anni. Questa guida tratta quindi entrambi gli aspetti.

Quale kernel sta eseguendo ora il tuo VPS

uname -r
uname -srm
systemd-detect-virt

uname -r stampa la release del kernel in esecuzione. Su Ubuntu 24.04 è simile a 6.8.0-79-generic. La parte prima del primo trattino indica la linea upstream. Tutto ciò che segue è il numero della build della distribuzione e non segue affatto il progetto upstream. Il 6.8.0-79 di Canonical include migliaia di correzioni retroportate da kernel più recenti, quindi non corrisponde al codice contrassegnato da Linus come 6.8 nel marzo 2024. Per questo motivo, dire «il mio kernel è vecchio» è meno significativo di quanto sembri. Le funzionalità sono vecchie. Le correzioni di sicurezza, di norma, non lo sono.

systemd-detect-virt indica se puoi modificare il kernel. Stampa kvm su una macchina virtuale completa, dove avvii una tua immagine del kernel e un aggiornamento è un vero aggiornamento. Stampa lxc o openvz nella virtualizzazione basata su container, dove il kernel dell'host è condiviso. In un piano basato su container, uname -r mostra il kernel del provider; installare un pacchetto del kernel non modifica nulla di ciò che puoi avviare e nessuna funzionalità di questa release è disponibile finché il provider non riavvia l'host con un kernel più recente. Esegui questo controllo prima di pianificare qualsiasi attività sul kernel.

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

Si tratta di 6 piattaforme e nessuna avvia la versione 7.1. La più recente è Ubuntu 26.04 LTS (7.0), che è indietro di 1 release upstream. La più vecchia ancora supportata è indietro di 26 release. Il kernel GA predefinito di Ubuntu 24.04 è indietro di 13 release, mentre Debian 13 e RHEL 10 sono indietro di 9 release rispetto alla linea longterm 6.12. Contare le release fornisce una misura approssimativa, perché non considera tutti i backport applicati dalle distribuzioni, ma mostra l'ampiezza del divario. Se stai valutando quale di queste utilizzare, il compromesso tra una release LTS e una release intermedia su un server è la decisione alla base di questi numeri.

Storage e filesystem in 7.1

La versione 7.1 aggiunge la possibilità di generare e verificare le T10 PI (protection information) all'interno del filesystem, invece che soltanto nel block layer, oltre al supporto flessibile per l'allineamento T10. Le T10 PI sono byte aggiuntivi associati a ogni blocco. Contengono un checksum e un tag che identifica il blocco a cui appartengono i dati. In questo modo una scrittura indirizzata al blocco errato o incompleta viene rilevata, invece di essere restituita come dati validi. Per un tenant VPS, il limite è l'hardware. Il dispositivo deve esporre i metadati di integrità, mentre un disco virtuale normalmente non li espone.

ls /sys/block/vda/integrity/

Sulla maggior parte dei dischi VPS questo comando restituisce No such file or directory, perché il block layer crea la directory integrity soltanto quando il dispositivo registra il supporto all'integrità. In questo caso l'errore è il risultato normale, non un malfunzionamento. Se vuoi sapere quale sia realmente il tuo disco prima di approfondire le funzionalità di storage, devi prima verificare se il disco VPS è effettivamente NVMe. La differenza tra NVMe e un SSD SATA su una VPS spiega perché il risultato modifica i valori ottenuti.

Btrfs corregge l'amplificazione delle operazioni copy-on-write sotto pressione della memoria. Include inoltre una modifica che velocizza la cancellazione del primo extent in un intervallo monitorato. Nel workload di esempio indicato nel merge, questa modifica ha prodotto un throughput superiore del 10%. L'operazione di shutdown non è più contrassegnata come sperimentale. XFS migliora il flushing degli intervalli azzerati e la ricerca tramite iomap. Aggiunge inoltre un write pointer alla geometria dei gruppi real-time, come base per il supporto ai dispositivi zoned. In questa release NTFS è stato completamente riscritto. Include il supporto completo alla scrittura e una conversione a iomap. Questo è rilevante se devi montare sul server un'immagine disco proveniente da una macchina Windows.

Altri aggiornamenti di storage da conoscere: ublk, il block driver in user space, ha acquisito l'I/O zero-copy; io_uring supporta i comandi passthrough SCSI; il supporto alle unità self-encrypting SED-OPAL include il comando STACK_RESET e la modalità single user estesa; è disponibile un nuovo character driver fs-dax per i dispositivi ad accesso diretto; e il VFS ha ampliato inode->i_ino da unsigned long a u64, rimuovendo il limite al numero di inode nelle build a 32 bit. Per quanto riguarda i filesystem di rete, il server NFS in kernel space può ora firmare i propri file handle tramite un'opzione di mount sign_fh, mentre il client CIFS supporta O_TMPFILE.

Networking: concessione delle code e cosa offre a un container

La principale modifica al networking riguarda la concessione delle code hardware. Un netdev virtuale può ora prendere in concessione una coda associata a una coda reale di un netdev fisico e fungere da proxy per essa. Questa funzione è pensata per i container. Finora, un container che richiedeva AF_XDP (address family express data path, il tipo di socket che trasferisce i pacchetti grezzi allo spazio utente senza copiarli attraverso lo stack di rete) doveva ricevere qualcosa di molto simile all’intero dispositivo. Con una coda in concessione, riceve una coda hardware, esegue AF_XDP e usa i memory provider alla velocità nativa, mentre l’host conserva il resto della NIC. Questa funzionalità si aggiunge al supporto per AF_XDP nel percorso zero-copy di io_uring.

Sul piano delle funzionalità ordinarie, i socket in sockfs ora accettano gli extended attribute user.*. Un socket AF_UNIX basato su un percorso ereditava già il supporto agli xattr dal filesystem sottostante, mentre un socket presente solo in sockfs ne era privo. Ora un processo può assegnare un’etichetta a un socket e un programma eBPF può filtrare in base a tale etichetta.

Sono state rimosse due funzionalità. UDP-Lite è stato eliminato perché non aveva utenti. IPv6 non può più essere compilato come modulo caricabile: se si vuole usare IPv6, deve essere compilato nel kernel. Questa seconda modifica è invisibile nei kernel delle distribuzioni, perché le principali distribuzioni server compilano già IPv6 direttamente nel kernel.

Gestione della memoria: la tabella di swap è completa

La revisione dello swap raggiunge la terza fase, che rimuove la mappa statica dello swap. Il conteggio delle aree di swap è ora memorizzato direttamente nella tabella di swap. Il risparmio dichiarato è pari a circa il 30% dei metadati statici dello swap. Si tratta di memoria che il kernel mantiene in proporzione alle dimensioni del dispositivo di swap, indipendentemente dal fatto che lo swap venga utilizzato. In termini assoluti, il risparmio è ridotto su un file di swap piccolo e aumenta con la quantità di swap configurata.

MGLRU (multi-generational least recently used, il nuovo algoritmo di reclaim delle pagine) può ora controllare il flag young delle pagine in batch, anziché una pagina alla volta. Il valore pubblicato con questa modifica indica un miglioramento superiore al 60% su un server Arm64 con 32 core. L'elaborazione in batch è più efficace quando il costo per pagina è maggiore. Per questo il valore è stato ottenuto su una macchina Arm di grandi dimensioni. Se usi un VPS Arm anziché uno x86, questa è la modifica di 7.1 che ha maggiori probabilità di emergere nelle tue misurazioni, anche se su due o quattro core i valori non raggiungeranno quella scala.

Sono incluse anche altre modifiche: non vengono più eseguiti trasferimenti dai memory cgroup in fase di terminazione, khugepaged esegue le scansioni con un uso inferiore della CPU e il maple tree ha subito un ampio refactoring nella gestione dei nodi di grandi dimensioni. Nessuna di queste funzionalità richiede configurazione. Si manifestano con una riduzione, seppur lieve, del tempo di sistema.

Scheduler: sub-scheduler sched_ext e FRED attivo per impostazione predefinita

sched_ext, la classe di scheduler estensibile che consente di scrivere uno scheduler CPU come programma BPF e caricarlo a runtime, è stata introdotta nella versione 6.12. La versione 7.1 aggiunge la struttura di base per i sub-scheduler, in modo che in futuro un control group possa usare un proprio scheduler. Questa distinzione è importante. L’implementazione non è completa nella versione 7.1 e manca in particolare il percorso di enqueue. Si tratta quindi delle fondamenta per una versione successiva, non di una funzionalità che si possa attivare oggi.

Intel FRED (flexible return and event delivery) è ora attivo per impostazione predefinita sull’hardware che lo supporta. FRED sostituisce il percorso legacy di event delivery di x86 con un’implementazione più semplice ed è presente nel kernel dalla versione 6.9, dietro l’argomento di boot fred=on. L’attivazione predefinita indica che l’hardware distribuito è stato testato a sufficienza. Le misurazioni pubblicate finora, comprese tra il 4% e il 7% sui carichi di lavoro con molto I/O, provengono da test Phoronix eseguiti su hardware client. Non considerate quindi questi valori nella pianificazione delle prestazioni di un server prima di avere misurato il vostro carico di lavoro.

La proxy execution ha aggiunto la migrazione del donor per aumentare la priorità del proprietario remoto di un lock, EEVDF ha ricevuto correzioni relative al lag negativo e il core dei timer ad alta risoluzione è stato riscritto in modo sostanziale. Sono modifiche che migliorano la latenza, ma che non espongono alcuna opzione nei file di configurazione.

Nuovi controlli per processi e container in clone3()

Sono stati aggiunti tre flag a clone3(). Ognuno risolve un limite che i supervisori hanno aggirato manualmente per anni. CLONE_AUTOREAP fa sì che il processo figlio si occupi autonomamente del proprio reaping all'uscita. In questo modo non diventa mai uno zombie in attesa di un processo padre che potrebbe non chiamare mai wait(). CLONE_NNP imposta no_new_privs sul processo figlio al momento della creazione. Questo elimina l'intervallo tra la chiamata a clone e l'impostazione autonoma del flag da parte del processo figlio. CLONE_PIDFD_AUTOKILL lega la durata del processo figlio al pidfd restituito al processo padre: quando il pidfd viene chiuso, il processo figlio viene terminato. In questo modo, se un supervisore termina, non può lasciare processi orfani in esecuzione.

Anche gli spazi dei nomi di mount hanno ricevuto lo stesso trattamento. CLONE_EMPTY_MNTNS per clone3() e UNSHARE_EMPTY_MNTNS per unshare() creano uno spazio dei nomi di mount vuoto, invece della consueta copia completa dei mount del processo padre, che il runtime deve poi smontare. FSMOUNT_NAMESPACE consente a fsmount() di inserire direttamente un filesystem in un nuovo spazio dei nomi. I runtime per container ricostruiscono questa configurazione manualmente da un decennio. Eseguire l'operazione con una sola chiamata evita quindi che il runtime parta da uno spazio dei nomi che contiene tutti i mount dell'host.

Per quanto riguarda la virtualizzazione, guest_memfd ora supporta userfaultfd. Un hypervisor può quindi gestire dallo spazio utente i page fault del guest. KVM protetto su Arm ha ottenuto il supporto per la memoria anonima. Il merge stesso specifica però che questa funzionalità non è pronta per l'uso in produzione.

Quando arriva il kernel 7.1 sul tuo server

Fedora lo include già. Il repository degli aggiornamenti di Fedora 44 è passato alla serie 7.1 tra luglio e agosto 2026, perché Fedora riallinea il kernel alle nuove serie stabili durante il ciclo di una release. Anche Arch e openSUSE Tumbleweed lo includono per lo stesso motivo. Sono sistemi adatti ai test, non all'esecuzione dei servizi.

Tutto il resto attende, per una scelta progettuale. Debian 13 è stata rilasciata con la versione 6.12 e resterà sulla 6.12 per tutta la durata della release, con le correzioni retroportate. RHEL 10 è stata rilasciata con la versione 6.12.0 e segue lo stesso modello. Ubuntu 26.04 LTS è stata rilasciata con la versione 7.0 ad aprile 2026. Ubuntu 24.04 LTS dispone di uno stack hardware enablement, che importa nella LTS un kernel più recente dalle release successive di Ubuntu. Questo stack usa la versione 6.17 a partire dalla point release 24.04.4 e dovrebbe passare alla versione 7.0 con la 24.04.5, prevista per il 27 agosto 2026.

Questo è il punto che spesso viene frainteso. Uno stack HWE passa al kernel incluso nella più recente release intermedia, quindi può saltare completamente una serie upstream. La versione 7.0 è inclusa in una Ubuntu LTS. La versione 7.1 potrebbe non diventare mai la base di una LTS, perché la release intermedia successiva includerà una serie più recente. Dalla versione 7.1 arrivano nella tua LTS le correzioni, retroportate nella serie che stai usando. Le funzionalità, nella maggior parte dei casi, restano nella serie upstream.

Se vuoi usare un kernel più recente su un server stabile, le modalità supportate sono poche.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

Dopo il riavvio, verifica quale kernel è stato effettivamente avviato:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r dovrebbe ora mostrare la nuova serie, mentre dpkg -l mostra tutte le immagini del kernel ancora installate. Se uname -r mostra la versione precedente e dpkg -l elenca quella nuova, il pacchetto è stato installato ma il valore predefinito del bootloader non è cambiato: controlla le voci del menu di GRUB. La presenza di /var/run/reboot-required indica che un pacchetto ha aggiornato il kernel e che da allora il sistema non è stato riavviato. Questa è la causa più comune per cui un server aggiornato con una patch continua a eseguire il codice vulnerabile.

Conviene inseguire la versione 7.1 su un VPS di produzione

No. Il motivo non è una cautela fine a se stessa. Il kernel della distribuzione fa parte di un contratto di supporto. Canonical, Red Hat, SUSE e Debian integrano le correzioni di sicurezza nella rispettiva linea stabile e le verificano con lo userspace distribuito insieme al kernel. Un kernel mainline proveniente da un archivio di terze parti o compilato manualmente offre le nuove funzionalità, ma elimina questo lavoro, perché nessuno integra le correzioni nella build che usi. Diventi tu il manutentore del kernel.

Le eccezioni esistono, ma sono limitate: hardware che il kernel precedente non riesce a gestire oppure una modifica delle prestazioni che hai misurato sul tuo carico di lavoro e che vuoi adottare al punto da assumerne le conseguenze. Su un VPS, il primo caso si verifica quasi mai, perché l'hardware visibile è virtuale. In tutti gli altri casi, mantieni aggiornato il kernel della distribuzione e riavvia quando viene richiesto. Se hai già pianificato un aggiornamento della distribuzione, passare da Ubuntu 24.04 a 26.04 ti porta dalla versione 6.8 alla 7.0 in un solo passaggio, con un salto maggiore di quello offerto da qualsiasi singolo pacchetto del kernel.

FAQ

Come posso verificare quale kernel Linux è in esecuzione sul mio VPS?

Eseguire uname -r. Il comando stampa un output simile a 6.8.0-79-generic. Il numero prima del primo trattino indica la versione upstream su cui si basa la distribuzione. Tutto ciò che segue è il numero di build specifico della distribuzione, che include correzioni backportate. Eseguire quindi systemd-detect-virt. Se stampa lxc o openvz, si usa la virtualizzazione tramite container, si condivide il kernel dell'host e non è possibile modificarlo. Se stampa kvm, il sistema avvia una propria immagine del kernel e gli aggiornamenti sono a carico dell'utente.

Linux 7.1 è un kernel con supporto a lungo termine?

No. All'11 agosto 2026, le versioni longterm elencate su kernel.org sono 6.18, 6.12, 6.6, 6.1, 5.15 e 5.10, mentre 7.1 non è incluso. È una normale release stable e la relativa serie stable viene dismessa poco dopo la pubblicazione della release mainline successiva. Se si desidera un kernel con anni di correzioni già disponibili e altri anni di supporto previsti, il kernel della propria distribuzione offre già queste caratteristiche.

Quando Ubuntu o Debian distribuiranno il kernel 7.1?

Probabilmente mai come versione predefinita. Debian 13 resta sulla versione 6.12 per tutto il ciclo di vita della release, mentre RHEL 10 resta sulla versione 6.12.0. Ubuntu 26.04 LTS è stata distribuita con 7.0 e uno stack Ubuntu hardware enablement passa alla versione del kernel inclusa nella release interim più recente; può quindi saltare completamente una serie upstream. Ubuntu 24.04 LTS dovrebbe aggiornare il proprio kernel HWE alla versione 7.0 con la point release 24.04.5 del 27 agosto 2026. Le correzioni di 7.1 arriveranno come backport nella serie precedente. Di norma, le nuove funzionalità non verranno incluse.

Quali aspetti di Linux 7.1 sono realmente importanti su un server privato virtuale?

Quattro aspetti. Il leasing delle code hardware consente a un container di usare una coda reale della NIC per AF_XDP alla velocità nativa. La terza fase della revisione del sottosistema swap rimuove la mappa swap statica e riduce del 30%, secondo quanto riportato, i metadati che il kernel mantiene per il dispositivo swap. MGLRU può verificare in batch i flag young delle pagine, con il maggiore incremento pubblicato su un server Arm con molti core. Inoltre, clone3() ha acquisito CLONE_AUTOREAP, CLONE_NNP e CLONE_PIDFD_AUTOKILL, che rendono più sicura la supervisione dei processi figli. È stata aggiunta anche la protezione T10 a livello di filesystem, ma un disco virtuale raramente espone i metadati di integrità necessari.

L'aggiornamento del kernel può danneggiare il mio VPS?

I problemi più comuni si verificano durante l'avvio. Un /boot completo fa fallire update-initramfs con No space left on device durante l'installazione e lascia il pacchetto configurato solo parzialmente: rimuovere i kernel obsoleti con sudo apt autoremove --purge, quindi reinstallare. I moduli esterni compilati per il kernel precedente non vengono più caricati. Di conseguenza, tutto ciò che è gestito da DKMS deve essere ricompilato, e una ricompilazione non riuscita può restare inosservata fino a quando il modulo non manca durante l'esecuzione. Se dopo un riavvio uname -r continua a riportare la versione precedente mentre dpkg -l elenca la nuova immagine, l'installazione non è danneggiata: il valore predefinito del bootloader non è stato modificato.