O ciclo de desenvolvimento do Linux 7.1, que se encaminha para o lançamento estável em meados de junho, atingiu no último domingo (31 de maio) a versão release candidate 6 (rc6). Embora o volume de mudanças tenha diminuído em relação ao rc5 da semana anterior, que gerou controvérsia, a torrente de patches originados por agentes de codificação com inteligência artificial persiste como um fenômeno estrutural no ecossistema do kernel.
rc6 é menor que rc5, mas a normalidade ainda não voltou
Na semana anterior, ao anunciar o rc5, Linus Torvalds deixou clara sua insatisfação com a quantidade de patches insignificantes gerados por ferramentas de revisão de código baseadas em IA. Ele classificou a situação como “churn sem sentido” (pointless churn) e alertou os mantenedores para que submetessem apenas correções críticas, adiando as demais para a próxima janela de merge. O rc5 havia atingido um tamanho atípico para um candidato a lançamento na fase final do ciclo.
O rc6 é menor. Nas palavras do próprio Torvalds, “não diria que é pequeno, mas certamente é menor que o rc5”. Ele acrescentou que “nada assustador apareceu” e que talvez o ciclo esteja retornando ao normal. “Vamos ver”, completou, sem fazer promessas.
O tom mais tranquilo, porém, não significa que o problema tenha sido resolvido. Na prática, a enxurrada de correções geradas por IA continua chegando. Especialmente no subsistema de rede, as pull requests originadas de LLMs ainda são maiores que o habitual, segundo Jakub Kicinski, mantenedor de networking.
A linha do tempo da invasão de patches de IA no Linux 7.1
O ciclo do Linux 7.1 já vinha apresentando esse padrão desde o rc2. O que parecia um pico temporário se confirmou como uma mudança estrutural: o número de patches com origem em IA não diminuiu com o avanço dos RCs. Veja o resumo cronológico:
| Data | RC | Observações |
|---|---|---|
| 26 de abril | rc1 | Fim da janela de merge. Aumento de patches com origem em IA é notado. 138 mil linhas de código antigo removidas em networking. Mantenedor descreve o aumento de relatos de bugs como “LLM-pocalypse”. |
| Início de maio | rc2-rc3 | Confirma-se que o aumento não é um pico, mas uma nova linha de base. |
| 17 de maio | rc4 | Torvalds critica duplicação de relatórios de segurança gerados por IA: ferramentas encontram o mesmo bug e múltiplas pessoas enviam o mesmo relato para listas fechadas. |
| 24 de maio | rc5 | Torvalds cita nominalmente GitHub Copilot e Claude Code. Tamanho excepcional para um RC5. Chama os patches de “pointless churn” e exige moderação. |
| 31 de maio | rc6 | Menor que rc5, mas ainda maior que o normal. Networking continua recebendo muitas PRs de IA. Torvalds não menciona IA diretamente, mas o silêncio indica que o fenômeno se tornou rotina. |
O comentário de Kicinski no rc5 — “não vejo fim para essa loucura. O pior ainda está por vir” — parece ter sido profético, já que o rc6 ainda carrega a herança do excesso.
O que há de concreto no rc6: drivers, rede, USB e virtualização
O log de commits do rc6 segue a descrição de Torvalds: “drivers aqui e ali”. As correções estão espalhadas por GPU, rede, USB, serial, som e SCSI. Destaques:
- Networking: o próprio Jakub Kicinski enviou nada menos que 25 correções para o ethtool, cobrindo contexto RSS, tratamento de erros em module flash, vazamentos de referência em timestamps e outros bugs na interface Netlink do ethtool. Além disso, há correções no conntrack do netfilter, prevenção de loops de pacotes (mirred redirect e pacotes duplicados no netem) e correção de sleep em contexto atômico no bridge.
- USB: uma série de correções de memory corruption em endpoints pequenos foi aplicada em sete drivers seriais USB: digi_acceleport, keyspan, mct_u232, cypress_m8, mxuport, omninet e safe_serial. No USB Type-C, o tcpm recebeu validação aprimorada de contagem VDO e robustez no processamento de discovery.
- KVM e virtualização: correções em SEV incluem ajuste de cálculo de tamanho de scratch area e reforço de verificação de limites do buffer PSC, aumentando a proteção contra requisições maliciosas de guests.
- Arquiteturas: patches para x86, MIPS e arm64 (principalmente KVM).
- Sistemas de arquivos: correções em SMB e NFS.
- Gerenciamento de memória e live update: também receberam ajustes.
O rc6 também adiciona suporte a dois novos controles de videogame: ASUS ROG RAIKIRI II e GameSir Nova 2 Lite.
Documentação do parâmetro clearcpuid é ocultada por risco de uso incorreto
Uma mudança sutil mas relevante: a documentação do parâmetro de kernel clearcpuidcodecodecodecode foi removida do conjunto público de documentos. Esse parâmetro permite desabilitar funcionalidades específicas da CPU no nível do kernel, mas não tem efeito sobre chamadas diretas de CPUID feitas por aplicações userspace. Além disso, desabilitar funcionalidades críticas pode fazer o próprio kernel funcionar mal. A decisão de ocultar a documentação visa evitar mau uso. O parâmetro em si continua existindo.
Previsão de lançamento estável do Linux 7.1
Com base no cronograma típico, se for necessário apenas um rc7, o Linux 7.1 estável chegaria em 14 de junho. Caso um rc8 seja requisitado, a data se estende para 21 de junho. O tom do anúncio do rc6 sugere que Torvalds gostaria de encerrar no rc7, mas ele não garantiu nada.
Embora o volume de patches tenha caído, resta saber se a redução é um sinal de que o fluxo de “churn de IA” está diminuindo ou apenas uma pausa forçada pelo aviso do criador do Linux. A dúvida permanece.
O dilema estrutural: correções corretas, no momento errado
O problema central não é que a IA esteja gerando patches incorretos. Pelo contrário, grande parte das correções é tecnicamente válida e contribui para a qualidade do código. A dificuldade está no timing: uma avalanche de patches mesmo que corretos, quando chega no fim do ciclo de release, compromete o esforço de estabilização. Encontrar bugs é uma habilidade; decidir quando corrigi-los é outra.
A primeira está sendo progressivamente dominada por IA. A segunda, por enquanto, ainda depende de julgamento humano. O Linux 7.1 está servindo como um estudo de caso sobre como o ecossistema de código aberto vai lidar com essa nova dinâmica nos próximos ciclos.
