Linux kernel 7.1: novita per i server e i VPS

Novità di Linux kernel 7.1

Linux kernel 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 riguardano 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 quasi certamente non è in esecuzione la versione 7.1 e non lo sarà ancora per molto tempo. kernel.org non indica la versione 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 oppure su una linea gestita autonomamente. Tra le novità del kernel e quelle effettivamente disponibili sul tuo server possono trascorrere anni: questa guida tratta quindi entrambi gli aspetti.

Quale kernel esegue attualmente il tuo VPS

uname -r
uname -srm
systemd-detect-virt

uname -r stampa la release del kernel in esecuzione. Su Ubuntu 24.04 ha un aspetto simile a 6.8.0-79-generic. La parte prima del primo trattino identifica la linea upstream. Tutto ciò che segue è il numero di build specifico della distribuzione e non corrisponde in alcun modo alle release 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 a marzo 2024. Per questo motivo, dire «il mio kernel è vecchio» fornisce meno informazioni di quanto sembri. Le funzionalità sono vecchie. Le correzioni di sicurezza, nella maggior parte dei casi, non lo sono.

systemd-detect-virt indica se puoi cambiare kernel. Stampa kvm su una macchina virtuale completa, nella quale avvii una tua immagine del kernel e un aggiornamento è un aggiornamento effettivo. Stampa lxc o openvz sulla virtualizzazione basata su container, nella quale il kernel dell'host è condiviso. Su un piano 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 sarà disponibile finché il provider non riavvierà l'host con un kernel più recente. Esegui questo controllo prima di pianificare qualsiasi intervento 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ù datata 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 è una misura approssimativa, perché non considera tutto ciò che le distribuzioni retroportano, ma mostra la dimensione del divario. Se stai valutando quale di queste eseguire, il compromesso tra release LTS e release intermedie su un server è la decisione alla base di questi numeri.

Storage e filesystem in 7.1

La versione 7.1 consente di generare e verificare le T10 PI (protection information) all'interno del filesystem, invece che soltanto nel livello a blocchi, e introduce anche un 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/

Nella maggior parte dei dischi VPS questo restituisce No such file or directory, perché il livello a blocchi crea la directory integrity soltanto quando il dispositivo registra il supporto all'integrità. In questo caso l'errore è il risultato previsto, non un malfunzionamento. Se vuoi sapere che tipo di disco utilizza realmente il tuo VPS 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 un VPS spiega perché la risposta modifica i tuoi valori.

Btrfs corregge l'amplificazione delle operazioni copy-on-write sotto pressione di memoria. Include anche una modifica che accelera 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 flush degli intervalli azzerati e le operazioni di lookup tramite iomap. Aggiunge inoltre un puntatore di scrittura alla geometria dei gruppi real-time, una base per il supporto dei dispositivi zoned. In questa release NTFS è stato completamente riscritto, con supporto completo alla scrittura e una conversione a iomap. Questo è utile se devi montare sul server un'immagine disco proveniente da una macchina Windows.

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

Networking: il leasing delle code e cosa offre a un container

Il principale cambiamento nel networking è il leasing delle code hardware. Un netdev virtuale può ora prendere in leasing una coda associata a una coda reale di un netdev fisico e usarla come proxy. Questa funzione è pensata per i container. Finora, un container che richiedeva AF_XDP (Address Family eXpress Data Path, il tipo di socket che consegna 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 presa in leasing, il container ottiene una coda hardware, esegue AF_XDP e usa i memory provider alla velocità nativa, mentre l'host conserva il resto della NIC. Questa funzione si aggiunge al supporto di AF_XDP nel percorso zero-copy di io_uring.

Sul lato più ordinario, i socket in sockfs accettano ora gli attributi estesi user.*. Un socket AF_UNIX basato su un percorso ereditava già il supporto agli xattr dal filesystem sottostante, ma un socket presente soltanto in sockfs non ne aveva alcuno. 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 desidera IPv6, deve essere compilato nel kernel. La seconda modifica non è visibile nei kernel delle distribuzioni, perché le principali distribuzioni server compilano già IPv6 direttamente nel kernel.

Gestione della memoria: la tabella di swap è completa

La riscrittura della gestione dello swap entra nella terza fase, che rimuove la mappa statica dello swap. Il conteggio delle aree di swap ora risiede 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 venga effettivamente utilizzato. In termini assoluti, il risparmio è ridotto con un file di swap piccolo e aumenta insieme alla quantità di swap configurata.

MGLRU (multi-generational least recently used, il nuovo algoritmo di recupero delle pagine) ora può controllare in batch il flag young delle pagine, invece di esaminare una pagina alla volta. Il dato pubblicato con questa modifica indica un miglioramento superiore al 60% su un server Arm64 a 32 core. L'elaborazione in batch è più efficace nei casi in cui il costo per pagina è maggiore. Per questo il dato è stato ottenuto su una macchina Arm di grandi dimensioni. Se usi un VPS Arm invece di uno x86, questa è la modifica di 7.1 che con maggiore probabilità noterai nelle tue misurazioni, anche se su due o quattro core il risultato non sarà dello stesso ordine di grandezza.

Sono incluse anche l'eliminazione dei trasferimenti dai memory cgroup in fase di terminazione, scansioni di khugepaged con un consumo inferiore di CPU e un'ampia ristrutturazione del maple tree per la gestione dei nodi di grandi dimensioni. Nessuno di questi aspetti richiede configurazione. Li noterai come una riduzione contenuta del tempo di sistema.

Scheduler: sottoscheduler sched_ext e FRED abilitato 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 sottoscheduler, in modo che in futuro un control group possa essere eseguito con il proprio scheduler. È importante interpretare correttamente questa frase. L’implementazione non è completa nella versione 7.1 e manca in particolare il percorso di enqueue. Si tratta quindi della base per una versione successiva, non di una funzionalità che si possa abilitare oggi.

Intel FRED (flexible return and event delivery) è ora abilitato per impostazione predefinita sull’hardware che lo supporta. FRED sostituisce il precedente percorso x86 per la gestione degli eventi con un’implementazione più semplice ed è presente nel kernel dalla versione 6.9, dietro l’argomento di boot fred=on. L’abilitazione predefinita indica che l’hardware disponibile è stato testato a sufficienza. Le misurazioni pubblicate finora, comprese tra il 4% e il 7% nei carichi di lavoro con molte operazioni di I/O, provengono da test Phoronix eseguiti su hardware client. Non è quindi opportuno prevedere gli stessi risultati su un server prima di aver misurato il proprio carico di lavoro.

L’esecuzione proxy ha introdotto la migrazione del donor per accelerare il lock owner remoto, 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 colma una lacuna che i supervisor hanno gestito manualmente per anni. CLONE_AUTOREAP fa in modo che il processo figlio venga raccolto automaticamente 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 il ciclo di vita del processo figlio al pidfd restituito al processo padre. Quando il pidfd viene chiuso, il processo figlio viene terminato. Un supervisor che termina non può quindi lasciare processi orfani in esecuzione.

Anche i mount namespace hanno ricevuto lo stesso trattamento. CLONE_EMPTY_MNTNS per clone3() e UNSHARE_EMPTY_MNTNS per unshare() creano un mount namespace vuoto, invece della normale copia completa dei mount del processo padre che un runtime dovrebbe poi smontare. FSMOUNT_NAMESPACE consente a fsmount() di inserire direttamente un filesystem in un nuovo namespace. I runtime per container costruiscono questa configurazione manualmente da dieci anni. Eseguire tutto con una sola chiamata evita che il runtime parta da un namespace che contiene tutti i mount dell'host.

Nel campo della virtualizzazione, guest_memfd supporta ora userfaultfd. Un hypervisor può quindi gestire in user space i page fault delle macchine guest. KVM Protected su Arm ha aggiunto il supporto per la memoria anonima, che il merge stesso descrive come non ancora pronto 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 proprio 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 sistemi su cui eseguire i propri servizi.

Tutto il resto aspetta, e l'attesa è prevista. Debian 13 è stata rilasciata con 6.12 e resta su 6.12 per tutta la durata della release, con le correzioni applicate tramite backport. RHEL 10 è stata rilasciata con 6.12.0 e segue lo stesso modello. Ubuntu 26.04 LTS è stata rilasciata con 7.0 ad aprile 2026. Ubuntu 24.04 LTS dispone di uno stack hardware enablement, che porta nella LTS un kernel più recente dalle release successive di Ubuntu; a partire dalla point release 24.04.4, questo stack usa 6.17 e dovrebbe passare a 7.0 con la 24.04.5 il 27 agosto 2026. Una point release non è una nuova versione di Ubuntu: è la stessa 24.04 con tutti gli aggiornamenti disponibili fino a quel momento integrati in nuovi supporti di installazione. Per questo, cosa cambia la 24.04.5 su un server che aggiorni già regolarmente riguarda la serie del kernel HWE e poco altro.

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 7.1 potrebbe non diventare mai la base di una LTS, perché la release intermedia successiva potrebbe includere una serie più recente. Dalla 7.1 arrivano nella tua LTS le correzioni, applicate tramite backport alla 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 opzioni supportate sono limitate.

# 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 mentre 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. È il motivo più comune per cui un server aggiornato continua a eseguire il codice vulnerabile.

Se dovresti 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 testano 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 tua build. Diventi tu il manutentore del kernel.

Le eccezioni esistono, ma sono limitate: hardware che il kernel precedente non è in grado di gestire oppure una modifica delle prestazioni che hai misurato sul tuo carico di lavoro e che vuoi adottare al punto da assumerti le relative conseguenze. Su un VPS, il primo caso si verifica quasi mai, perché l'hardware visibile è virtuale. Per tutto il resto, mantieni aggiornato il kernel della distribuzione e riavvia quando 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 esegue il mio VPS?

Esegui uname -r. Il comando stampa un output simile a 6.8.0-79-generic. Il numero prima del primo trattino indica la linea upstream su cui si basa la build della distribuzione; tutto ciò che segue è il numero di build specifico della distribuzione, che include correzioni retroportate. Esegui quindi systemd-detect-virt. Se stampa lxc o openvz, usi la virtualizzazione basata su container, condividi il kernel dell'host e non puoi modificarlo. Se stampa kvm, avvii una tua immagine del kernel e gli aggiornamenti sono a tuo carico.

Linux 7.1 è un kernel con supporto a lungo termine?

No. All'11 agosto 2026, le linee con supporto a lungo termine elencate su kernel.org sono 6.18, 6.12, 6.6, 6.1, 5.15 e 5.10; la 7.1 non è tra queste. È una normale release stabile e la relativa linea stable viene abbandonata poco dopo la pubblicazione della release mainline successiva. Se vuoi un kernel che abbia alle spalle anni di correzioni e che ne riceva ancora per anni, è già quello fornito dalla tua distribuzione.

Quando Ubuntu o Debian distribuiranno il kernel 7.1?

Probabilmente mai come versione predefinita. Debian 13 rimane sulla 6.12 per tutta la durata della release e RHEL 10 rimane sulla 6.12.0. Ubuntu 26.04 LTS è stata distribuita con la 7.0 e uno stack Ubuntu hardware enablement passa al kernel utilizzato dalla release interim più recente; può quindi saltare completamente una linea upstream. Ubuntu 24.04 LTS dovrebbe aggiornare il proprio kernel HWE alla 7.0 con la point release 24.04.5 del 27 agosto 2026. Le correzioni della 7.1 ti arriveranno come backport in una linea precedente. Di norma, le funzionalità non arriveranno.

Quali aspetti di Linux 7.1 sono realmente rilevanti su un virtual private server?

Quattro elementi. L'assegnazione 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 dello swap rimuove la mappa statica dello swap e riduce del 30%, secondo quanto riportato, i metadati che il kernel conserva per il dispositivo di swap. MGLRU può controllare in batch i flag di attività 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. Sono state aggiunte anche le protection information T10 a livello di filesystem, ma un disco virtuale raramente espone i metadati di integrità necessari.

L'aggiornamento del kernel può compromettere 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: rimuovi i kernel obsoleti con sudo apt autoremove --purge, quindi reinstalla. I moduli esterni all'albero del kernel compilati per il kernel precedente smettono di essere caricati. Di conseguenza, tutto ciò che è gestito da DKMS deve essere ricompilato e un errore nella ricompilazione resta inosservato finché 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: non è stata aggiornata l'impostazione predefinita del bootloader.