Linux kernel 7.1: novidades para servidores

O que há de novo no Linux kernel 7.1

O Linux kernel 7.1 foi lançado em 14 June 2026, nove semanas depois da versão 7.0. Para um utilizador de VPS (virtual private server), as alterações relevantes estão concentradas em quatro áreas: armazenamento e sistemas de ficheiros, rede, gestão de memória e controlo de processos e contentores. O restante lançamento é sobretudo trabalho relacionado com ambientes de trabalho e gráficos, que um servidor sem interface gráfica nunca carrega.

Há uma segunda resposta que precisa de conhecer primeiro. É quase certo que a versão 7.1 não está em execução no seu servidor e que isso não acontecerá durante bastante tempo. O kernel.org não lista a versão 7.1 como uma versão longterm. Em 11 August 2026, as linhas longterm são 6.18, 6.12, 6.6, 6.1, 5.15 e 5.10, e todas as principais distribuições de servidores se baseiam numa dessas linhas ou numa linha que mantêm internamente. A diferença entre "novidades no kernel" e "novidades no seu servidor" é de vários anos. Por isso, este guia aborda ambas as situações.

Qual kernel o seu VPS está executando agora

uname -r
uname -srm
systemd-detect-virt

uname -r exibe a versão do kernel em execução. No Ubuntu 24.04, o resultado é semelhante a 6.8.0-79-generic. A parte antes do primeiro hífen indica a linha upstream. Tudo depois dela é o número de compilação específico da sua distribuição e não acompanha o upstream. O 6.8.0-79 da Canonical inclui milhares de correções retroportadas de kernels posteriores, portanto não é o código que Linus marcou como 6.8 em março de 2024. Por isso, dizer que “meu kernel é antigo” informa menos do que parece. Os recursos são antigos. As correções de segurança normalmente não são.

systemd-detect-virt informa se você pode alterar o kernel. O resultado é kvm em uma máquina virtual completa, na qual você inicializa a sua própria imagem de kernel e uma atualização é uma atualização real. O resultado é lxc ou openvz em uma virtualização baseada em contêineres, na qual o kernel do host é compartilhado. Em um plano de contêiner, uname -r mostra o kernel do provedor. Instalar um pacote de kernel não altera nada que você possa inicializar, e nenhum recurso desta versão estará disponível até que o provedor reinicie o host com um kernel mais recente. Execute esta verificação antes de planejar qualquer trabalho no 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"
  }
]

São 6 plataformas, e nenhuma inicializa o kernel 7.1. A mais recente é Ubuntu 26.04 LTS (7.0), que está 1 versão upstream atrás. A mais antiga ainda com suporte está 26 versões atrás. O kernel GA padrão do Ubuntu 24.04 está 13 versões atrás, enquanto Debian 13 e RHEL 10 estão 9 versões atrás, na linha 6.12 de suporte de longo prazo. Contar versões é uma medida aproximada, porque ignora tudo o que as distribuições retroportam, mas mostra a dimensão da diferença. Se você estiver avaliando qual delas usar, a decisão entre LTS e uma versão interim em um servidor é o ponto central por trás desses números.

Armazenamento e sistemas de ficheiros no 7.1

O 7.1 adiciona a capacidade de gerar e verificar T10 PI (informações de proteção) dentro do sistema de ficheiros, em vez de apenas na camada de blocos, além de suporte flexível para alinhamento T10. O T10 PI consiste em bytes adicionais associados a cada bloco. Esses bytes contêm uma soma de verificação e uma etiqueta que identifica a que bloco pertencem os dados. Assim, uma escrita direcionada para o bloco errado ou incompleta é detetada, em vez de os dados serem devolvidos como válidos. Para um utilizador de VPS, a limitação é o hardware. Os metadados de integridade têm de ser expostos pelo dispositivo, mas um disco virtual normalmente não os expõe.

ls /sys/block/vda/integrity/

Na maioria dos discos de VPS, isso devolve No such file or directory, porque a camada de blocos só cria o diretório integrity quando o dispositivo regista suporte de integridade. Esse erro é a resposta normal neste caso, não uma falha. Se quiser saber como é realmente o seu disco antes de avançar na análise das funcionalidades de armazenamento, deve começar por verificar se o disco da VPS é realmente NVMe. A diferença entre NVMe e um SSD SATA numa VPS explica por que motivo a resposta altera os seus valores.

O Btrfs recebe correções para a amplificação de copy-on-write sob pressão de memória, além de uma alteração que acelera a limpeza do primeiro extent num intervalo monitorizado. O merge que introduz a alteração relata um aumento de 10% no débito da carga de trabalho usada no teste. A operação de encerramento deixou de estar marcada como experimental. O XFS melhora a descarga de intervalos preenchidos com zeros e a pesquisa através de iomap. Também adiciona um ponteiro de escrita à geometria dos grupos de tempo real, o que prepara o suporte para dispositivos zoned. O NTFS foi completamente reescrito nesta versão, com suporte total de escrita e conversão para iomap. Isto é relevante se alguma vez montar no servidor uma imagem de disco proveniente de uma máquina Windows.

Outros itens de armazenamento que vale a pena conhecer: ublk, o controlador de blocos em espaço de utilizador, passou a ter I/O sem cópia; o io_uring passou a aceitar comandos de passthrough SCSI; o suporte para unidades com encriptação própria SED-OPAL recebeu o comando STACK_RESET e o modo de utilizador único expandido; foi adicionado um novo controlador de caracteres fs-dax para dispositivos de acesso direto; e o VFS aumentou inode->i_ino de unsigned long para u64, eliminando o limite do número de inode nas compilações de 32 bits. No lado dos sistemas de ficheiros de rede, o servidor NFS no kernel pode agora assinar os seus file handles através de uma opção de montagem sign_fh, e o cliente CIFS passou a reconhecer O_TMPFILE.

Rede: leasing de filas e o que isso oferece a um contentor

A principal alteração na rede é o leasing de filas de hardware. Um netdev virtual pode agora obter uma fila associada a uma fila real de um netdev físico e atuar como proxy dessa fila. O objetivo são os contentores. Até agora, um contentor que precisasse de AF_XDP (address family express data path, o tipo de socket que entrega pacotes em bruto ao espaço de utilizador sem os copiar através da pilha de rede) tinha de receber algo próximo do dispositivo completo. Com uma fila obtida por leasing, recebe uma fila de hardware, executa AF_XDP e utiliza memory providers à velocidade nativa, enquanto o host mantém o restante da NIC. Esta alteração surge juntamente com o suporte para AF_XDP no caminho de cópia zero do io_uring.

No funcionamento normal, os sockets em sockfs aceitam agora user.* atributos estendidos. Um socket AF_UNIX baseado num caminho já herdava o suporte para xattr do sistema de ficheiros subjacente, mas um socket existente apenas em sockfs não tinha esse suporte. Agora um processo pode atribuir uma etiqueta a um socket, e um programa eBPF pode filtrar com base nessa etiqueta.

Foram removidos dois componentes. O UDP-Lite foi removido por não ter utilizadores. O IPv6 já não pode ser compilado como módulo carregável: se quiser IPv6, este é compilado diretamente no kernel. A segunda alteração não é visível em nenhum kernel de distribuição, porque as distribuições comuns para servidores já compilam o IPv6 diretamente no kernel.

Gestão de memória: a tabela de swap está concluída

A reformulação do swap chega à terceira fase, que remove o mapa estático de swap. A contagem de swap passa agora a ficar diretamente na tabela de swap. A poupança indicada é de cerca de 30% dos metadados estáticos de swap. Trata-se de memória que o kernel mantém proporcionalmente ao tamanho do dispositivo de swap, independentemente de existir ou não paginação para swap. Em termos absolutos, o valor é pequeno num ficheiro de swap pequeno e aumenta com o tamanho de swap configurado.

O MGLRU (multi-generational least recently used, o algoritmo mais recente de recuperação de páginas) pode agora verificar a flag young das páginas em lotes, em vez de processar uma página de cada vez. O valor publicado com esta alteração indica uma melhoria superior a 60% num servidor Arm64 com 32 cores. O processamento em lotes é mais vantajoso quando o custo por página é mais elevado. É por isso que esse valor foi obtido numa máquina Arm de grandes dimensões. Se executar uma VPS Arm em vez de uma VPS x86, esta é a alteração do 7.1 com maior probabilidade de aparecer nas suas próprias medições, embora não nessa escala num sistema com dois ou quatro cores.

Também foram incluídas estas alterações: deixaram de existir transferências para fora de memory cgroups em processo de eliminação, o khugepaged faz verificações com menor utilização de CPU e a maple tree recebeu uma grande reformulação no tratamento dos nós grandes. Nenhuma destas alterações requer configuração. O efeito é uma ligeira redução do tempo de sistema.

Agendadores: subagendadores sched_ext e FRED ativado por padrão

sched_ext, a classe de agendador extensível que permite escrever um agendador de CPU como um programa BPF e carregá-lo em tempo de execução, chegou no 6.12. A versão 7.1 adiciona a estrutura central para subagendadores, para que um grupo de controlo possa futuramente usar o seu próprio agendador. Leia essa frase com atenção. A implementação não está concluída na 7.1 e, em particular, falta o caminho de enfileiramento. Isto é trabalho preparatório para uma versão posterior, não algo que possa ativar hoje.

O Intel FRED (flexible return and event delivery) agora está ativado por padrão no hardware que o suporta. O FRED substitui o caminho legado de entrega de eventos do x86 por um caminho mais simples e está no kernel desde a 6.9, condicionado ao argumento de arranque fred=on. Ativá-lo por padrão indica que o hardware disponível foi suficientemente testado. As medições publicadas até agora, entre 4% e 7% em cargas de trabalho intensivas em E/S, vêm de testes do Phoronix em hardware cliente. Portanto, não faça previsões desse ganho para um servidor sem medir primeiro a sua própria carga de trabalho.

A execução por procuração passou a suportar a migração do doador para acelerar o proprietário remoto de um lock, o EEVDF recebeu correções relacionadas com lag negativo e o núcleo dos temporizadores de alta resolução foi reescrito em grande parte. Estas alterações melhoram a latência, mas não são expostas por nenhum ficheiro de configuração.

Novos controles de processos e contentores em clone3()

Foram adicionadas três flags a clone3(). Cada uma elimina uma limitação que os supervisores contornam manualmente há anos. CLONE_AUTOREAP faz com que o processo filho recolha o seu próprio estado ao terminar. Assim, nunca se torna um processo zombie à espera de um processo pai que pode nunca chamar wait(). CLONE_NNP define no_new_privs no processo filho durante a criação. Isto elimina o intervalo entre a chamada a clone e o momento em que o processo filho define a flag por si próprio. CLONE_PIDFD_AUTOKILL associa o ciclo de vida do processo filho ao pidfd devolvido ao processo pai. Quando o pidfd é fechado, o processo filho é terminado. Assim, um supervisor que termine não deixa processos órfãos em execução.

Os namespaces de montagem receberam o mesmo tratamento. CLONE_EMPTY_MNTNS para clone3() e UNSHARE_EMPTY_MNTNS para unshare() criam um namespace de montagem vazio, em vez de uma cópia completa das montagens do processo pai, que depois teria de ser desmontada pelo runtime. FSMOUNT_NAMESPACE permite que fsmount() coloque um sistema de ficheiros diretamente num namespace novo. Os runtimes de contentores montam esta estrutura manualmente há uma década. Fazê-lo numa única chamada significa que um runtime já não começa com um namespace cheio das montagens do host.

Na área da virtualização, guest_memfd passou a suportar userfaultfd. Assim, um hypervisor pode tratar falhas de páginas do guest a partir do espaço de utilizador. O KVM protegido em Arm passou a suportar memória anónima. O próprio merge descreve esta funcionalidade como não estando pronta para produção.

Quando o kernel 7.1 chega ao seu servidor

O Fedora já o tem. O repositório de atualizações do Fedora 44 passou para a série 7.1 durante julho e agosto de 2026, porque o Fedora rebaseia o seu kernel para novas séries estáveis durante o ciclo de uma versão. O Arch e o openSUSE Tumbleweed também o têm pelo mesmo motivo. Essas são máquinas para testar, não máquinas para executar os seus serviços.

Todo o resto espera, e essa espera é intencional. O Debian 13 foi lançado com o 6.12 e mantém-se no 6.12 durante todo o ciclo da versão, com as correções integradas nessa série. O RHEL 10 foi lançado com o 6.12.0 e faz o mesmo. O Ubuntu 26.04 LTS foi lançado com o 7.0 em abril de 2026. O Ubuntu 24.04 LTS tem uma stack de habilitação de hardware, que traz para o LTS um kernel mais recente das versões posteriores do Ubuntu. Essa stack está no 6.17 desde a point release 24.04.4 e está programada para passar ao 7.0 com a 24.04.5 em 27 de agosto de 2026. Uma point release não é uma nova versão do Ubuntu. É o mesmo 24.04 com todas as atualizações disponibilizadas até então integradas em novos meios de instalação. Por isso, o que a versão 24.04.5 altera num servidor que já atualiza é a série de kernels HWE, e pouco mais.

É aqui que muitas pessoas se enganam. Uma stack HWE passa para o kernel incluído na versão interim mais recente, pelo que pode saltar completamente uma série upstream. O 7.0 está num Ubuntu LTS. O 7.1 pode nunca ser a base de um LTS, porque a versão interim seguinte terá uma série posterior. O que chega ao seu LTS a partir do 7.1 são as correções, integradas na série que estiver a utilizar. As funcionalidades ficam, na sua maioria, na série upstream.

Se quiser mesmo um kernel mais recente num servidor estável, as opções suportadas são poucas.

# 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

Depois do reboot, confirme qual kernel foi efetivamente iniciado:

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

uname -r deverá agora mostrar a nova série, e dpkg -l mostra todas as imagens de kernel que continuam instaladas. Se uname -r mostrar a versão antiga enquanto dpkg -l lista a nova, o pacote foi instalado, mas a predefinição do bootloader não mudou: consulte as entradas do GRUB. A existência de /var/run/reboot-required significa que um pacote atualizou o kernel e que ainda não foi feito nenhum reboot. Essa é a razão mais comum para um servidor corrigido continuar a executar o código vulnerável.

Por que não deve perseguir o 7.1 num VPS de produção

Não. E o motivo não é cautela por si só. O kernel da distribuição é um contrato de suporte. Canonical, Red Hat, SUSE e Debian fazem backport das correções de segurança para a sua linha congelada e testam-nas com o userspace que distribuem juntamente com ela. Um kernel mainline de um arquivo de terceiros ou compilado manualmente fornece as funcionalidades, mas retira-lhe esse trabalho, porque ninguém faz backport das correções para a sua compilação. Passa a ser o responsável pela manutenção de um kernel.

As exceções existem, mas são restritas: hardware que o kernel mais antigo não consegue controlar ou uma alteração de desempenho que tenha medido na sua própria carga de trabalho e que queira aplicar o suficiente para assumir as consequências. Num VPS, a primeira situação quase nunca se aplica, porque o hardware que vê é virtual. Em todos os outros casos, mantenha o kernel da distribuição atualizado e reinicie quando for solicitado. Se uma atualização da distribuição já estiver na sua lista, passar do Ubuntu 24.04 para o 26.04 leva-o do 6.8 para o 7.0 numa única etapa, o que representa um salto maior do que qualquer pacote de kernel individual lhe proporcionará.

FAQ

Como verifico qual kernel Linux o meu VPS está a executar?

Execute uname -r. O comando apresenta algo semelhante a 6.8.0-79-generic. O número antes do primeiro hífen é a versão principal na qual a sua distribuição se baseia. Tudo o que aparece depois é o número de compilação próprio da distribuição, que inclui correções retroportadas. Em seguida, execute systemd-detect-virt. Se apresentar lxc ou openvz, está a utilizar virtualização por contentores, partilha o kernel do host e não pode alterá-lo. Se apresentar kvm, arranca a sua própria imagem de kernel e é responsável pelas respetivas atualizações.

O Linux 7.1 é um kernel com suporte de longo prazo?

Não. Em 11 August 2026, as linhas com suporte de longo prazo listadas em kernel.org são 6.18, 6.12, 6.6, 6.1, 5.15 e 5.10, e a 7.1 não está entre elas. É uma versão estável normal. A respetiva linha estável deixa de receber manutenção pouco depois de surgir a versão mainline seguinte. Se pretende um kernel com anos de correções já aplicadas e vários anos de correções futuras, é isso que o kernel da sua distribuição já fornece.

Quando é que Ubuntu ou Debian vão lançar o kernel 7.1?

Provavelmente nunca como versão predefinida. Debian 13 mantém-se na versão 6.12 durante todo o ciclo da versão, e RHEL 10 mantém-se na versão 6.12.0. Ubuntu 26.04 LTS foi lançado com a versão 7.0. Uma stack Ubuntu de hardware enablement passa para o kernel incluído na versão interim mais recente, pelo que pode ignorar completamente uma linha upstream. Ubuntu 24.04 LTS está prevista para atualizar o seu kernel HWE para a versão 7.0 com a versão pontual 24.04.5, em 27 August 2026. As correções da versão 7.1 chegarão através de backports para uma linha mais antiga. Normalmente, as funcionalidades não serão incluídas.

O que é realmente importante no Linux 7.1 para um servidor privado virtual?

Há quatro itens. O hardware queue leasing permite que um contentor utilize uma fila real de uma NIC para AF_XDP à velocidade nativa. A terceira fase da reformulação do swap remove o mapa estático de swap e reduz em 30% os metadados que o kernel mantém para o dispositivo de swap, segundo os valores publicados. MGLRU pode verificar em lotes os page young flags, com o maior ganho publicado num servidor Arm com muitos cores. E clone3() ganhou CLONE_AUTOREAP, CLONE_NNP e CLONE_PIDFD_AUTOKILL, que tornam mais segura a supervisão de processos filho. A proteção T10 ao nível do sistema de ficheiros também foi incluída, mas um disco virtual raramente expõe os metadados de integridade de que necessita.

A atualização do kernel pode avariar o meu VPS?

As falhas mais comuns acontecem durante o arranque. Um /boot completo faz update-initramfs falhar com No space left on device durante a instalação e deixa o pacote parcialmente configurado: remova os kernels antigos com sudo apt autoremove --purge e reinstale. Os módulos externos compilados para o kernel antigo deixam de carregar. Tudo o que for gerido pelo DKMS tem de ser recompilado, e uma recompilação falhada só é detetada quando o módulo está em falta durante a execução. Se uname -r continuar a apresentar a versão antiga depois de um reboot, enquanto dpkg -l lista a nova imagem, a instalação não falhou: a predefinição do bootloader não foi alterada.