Em 8 de fevereiro de 2026, logo após liberar o Linux 6.19, Linus Torvalds confirmou que a próxima versão do kernel seria a 7.0. Não a 6.20. A decisão segue um padrão que se repete desde 2019: quando os números menores ficam grandes demais, Torvalds reseta o contador. Aconteceu com o 5.0 (março de 2019, após o 4.20) e com o 6.0 (outubro de 2022, após o 5.19).

O que torna o 7.0 interessante não é o número em si. É o que veio junto: um filesystem que não armazena nada, filtros BPF dentro do io_uring, ganhos reais de performance na criação de threads e mais espaço para Rust no kernel. A release estável está prevista para o início de abril, a tempo de entrar no Ubuntu 26.04 LTS.

Por que 7.0 e não 6.20

Torvalds explicou a mudança com o humor habitual: "I'm getting to the point where I'm being confused by large numbers (almost running out of fingers and toes again)." No anúncio do rc1, reforçou: "We have a new major number purely because I'm easily confused and not good with big numbers."

Para quem trabalha com o kernel no dia a dia, isso não muda nada. Ao contrário do versionamento semântico, onde um bump de major indica breaking changes, o Linux não segue essa convenção. O salto de 6.19 para 7.0 carrega exatamente o mesmo peso que o de 6.18 para 6.19. Interfaces estáveis continuam estáveis. Módulos compilados para 6.x não vão funcionar no 7.0 de qualquer forma, porque o kernel nunca garantiu ABI estável entre releases.

O padrão se repete a cada 19 ou 20 versões menores. É pragmatismo puro: números menores acima de 20 ficam confusos em conversas, scripts e documentação.

nullfs e o isolamento de containers

Uma das primeiras features mergeadas no 7.0 foi o nullfs, um filesystem vazio por definição. Ele não armazena arquivos, não tem inodes, não ocupa espaço. Parece inútil à primeira vista, mas resolve um problema concreto.

Hoje, quando o kernel cria um mount namespace novo, ele precisa de pelo menos um filesystem montado como raiz. Com o nullfs, é possível criar namespaces com zero mounts reais. O uso imediato no 7.0 é simplificar a vida de programas init: em vez de montar um tmpfs descartável só para satisfazer o requisito do namespace, o init pode usar nullfs como placeholder.

Mas o plano vai além. Em releases futuras, o nullfs deve ser usado para isolar kernel threads do processo init, reduzindo a superfície de ataque. Para quem opera containers em produção, isso se traduz em sandboxes mais apertadas sem overhead adicional.

Junto com o nullfs, o 7.0 traz o OPEN_TREE_NAMESPACE, que permite criar mount namespaces de forma mais granular. Combinados, os dois recursos dão aos runtimes de container (runc, crun, youki) ferramentas mais precisas para controlar o que cada processo enxerga do sistema de arquivos.

Filtros BPF no io_uring

O io_uring ganhou suporte a filtros BPF, implementado por Jens Axboe. A ideia é permitir que programas BPF inspecionem operações na Submission Queue Entry (SQE) e decidam se a operação deve ser permitida ou negada.

Alguns detalhes que importam:

  • Os filtros usam classic BPF, não eBPF. A escolha foi deliberada: classic BPF é mais simples de auditar e roda em contextos onde eBPF não é permitido, como dentro de containers com seccomp restrito
  • Múltiplos filtros podem ser empilhados por opcode, criando camadas de validação
  • O filtro inspeciona atributos do request e toma decisões dinâmicas, similar ao que seccomp faz com syscalls

Na prática, isso abre caminho para políticas de segurança mais finas em aplicações que usam io_uring. Um runtime de container pode, por exemplo, permitir operações de leitura no io_uring mas bloquear escritas em determinados file descriptors, sem recorrer a seccomp para interceptar syscalls inteiras.

Ganhos de performance no VFS

O subsistema VFS (Virtual File System) recebeu várias otimizações no 7.0. Duas se destacam pelos números:

Alocação de PID refatorada. O mecanismo de alocação de Process IDs foi reescrito para reduzir false sharing entre CPUs. O resultado: melhoria de 10 a 16% no throughput de criação e destruição de threads, dependendo do layout de cache do hardware. Para workloads que criam threads em alta frequência (servidores web, pools de conexão, workers de fila), esse ganho aparece direto nos benchmarks.

Tracking de file locks otimizado. O rastreamento de presença de locks em arquivos foi simplificado, gerando ganho de 4 a 16% em benchmarks de open-in-a-loop. Aplicações que abrem e fecham arquivos repetidamente, como build systems e ferramentas de CI, se beneficiam.

Além dessas, o 7.0 traz timestamps não-bloqueantes: o file_update_time_flags() agora propaga a flag IOCB_NOWAIT pelo caminho de ->update_time, permitindo que filesystems com timestamps granulares atualizem sem penalidade de bloqueio. Isso reduz latência em operações de I/O assíncrono.

Outra adição é a infraestrutura fserror, que padroniza o report de erros de I/O via fsnotify. Antes, cada filesystem (xfs, ext4, erofs, f2fs) implementava seu próprio mecanismo de report. Agora existe uma interface comum baseada em struct super_block, com mempools e queue_work para evitar segurar locks do filesystem no caminho de notificação.

Rust ganha terreno no kernel

O Linux 7.0 não é o release que coloca Rust no centro do palco, mas consolida o progresso dos últimos dois anos. Desde dezembro de 2025, Rust deixou de ser experimental no kernel. O anúncio foi feito no Linux Kernel Developers Summit: as linguagens core do kernel passaram a ser C, assembly e Rust.

No 7.0 especificamente, o destaque é o suporte a Rust LTO (Link-Time Optimization) para builds do kernel, usando __rust_helper. Isso permite que o compilador otimize código Rust e C juntos no momento da linkagem, eliminando overhead em chamadas entre os dois mundos.

O projeto DRM (Direct Rendering Manager), responsável pela stack gráfica, anunciou que está a cerca de um ano de exigir Rust para novos drivers, proibindo C. Greg Kroah-Hartman, um dos principais mantenedores do kernel, declarou que drivers em Rust se mostraram mais seguros que os equivalentes em C, com performance equivalente graças às zero-cost abstractions.

Para o ecossistema mais amplo, o sinal é claro. O Debian vai exigir Rust no APT a partir de maio de 2026. A combinação de kernel + distribuições adotando Rust como requisito cria um ponto de inflexão para quem mantém infraestrutura Linux.

Quando esperar o 7.0 em produção

O timeline do 7.0:

  • 8 de fevereiro de 2026: Linus confirma o 7.0, abre o merge window
  • 22 de fevereiro: rc1 liberado
  • 1 de março: rc2 liberado (maior que o esperado, segundo Torvalds, por trabalho acumulado do 6.19)
  • Início de abril: release estável prevista
  • 23 de abril: Ubuntu 26.04 LTS, que deve incluir o 7.0 como kernel padrão

O kernel freeze do Ubuntu 26.04 está marcado para 16 de abril. Se o 7.0 estável sair antes disso, entra como kernel padrão da próxima LTS. A Canonical já começou o trabalho de integração a partir do rc1.

Fedora 44 também deve adotar o 7.0. Para distribuições rolling release como Arch Linux, a adoção tende a ser ainda mais rápida.

O 7.0 também inclui enablement para Intel Nova Lake e AMD Zen 6, o que significa melhor suporte de hardware para quem está planejando renovação de servidores em 2026.

Conclusão

O número 7.0 não significa ruptura. Significa que Torvalds prefere contar nos dedos. Mas o conteúdo deste release tem substância real: nullfs endereça um gap antigo no isolamento de namespaces, os filtros BPF no io_uring abrem possibilidades novas de segurança em I/O assíncrono, e as otimizações de VFS entregam ganhos mensuráveis em workloads comuns.

O avanço de Rust no kernel também merece atenção. Não por ser novidade, mas por estar se tornando requisito. Quando o DRM exigir Rust para novos drivers e o Debian colocar Rust como dependência do APT, a cadeia inteira de quem opera Linux em produção vai sentir.

Se você opera Ubuntu em produção, o 7.0 deve chegar com o 26.04 LTS em abril. Para quem roda Fedora ou Arch, mais cedo ainda. Em qualquer caso, vale acompanhar os release candidates que saem a cada semana até a release estável.

Referências pesquisadas nesta publicação