Herbert Xu, mantenedor do subsistema de criptografia do Kernel Linux, enviou um git pull aparentemente de rotina para o Linux 6.17: uma correção que ajustava o limite estático HASH_MAX_DESCSIZE para que um algoritmo específico voltasse a registrar. O que veio depois foi uma clássica “bronca” de Linus Torvalds — não sobre a correção em si, mas sobre a falta de explicação. Um lembrete público do padrão de desenvolvimento e comunicação que o projeto exige.
A correção de um byte e a bronca de Linus
O resumo do pull request dizia: “This push fixes a regression that breaks hmac(sha3-224-s390)”. A mudança? Trocar um número no cabeçalho: de 360 para 361. Só que “360 → 361” não conta a história completa. Linus respondeu pedindo o que deveria ser óbvio em qualquer mensagem de commit: o contexto. Nas palavras dele: “Please describe the completely random strange constants, and why they changed… What is ‘361’, and why did 360 use to work but no longer does?” Ele ainda reforçou que o código não deveria carregar “números mágicos” sem uma explicação clara.
Esse é um ponto cultural, não só técnico. Em um projeto do tamanho e da longevidade do Linux, commits são mais do que “o que mudou”: eles documentam por que algo mudou, para que qualquer pessoa — daqui a meses ou anos — consiga entender e manter o código. Linus aceitou a correção (ela de fato consertava um bug), mas deixou claro que tanto o pull message quanto o commit “não tinham explicações aceitáveis”. É a pedagogia direta de quem sabe que um repositório saudável depende de histórico legível.
Por trás do “número mágico”: o contexto técnico
A explicação técnica que faltou no commit apareceu na thread logo depois, pela voz de Vegard Nossum (com base em um e-mail de Eric Biggers). O diagnóstico: uma mudança anterior no driver s390/sha3 passou a usar o “partial block handling” da Crypto API, o que aumentou em 1 byte o descsize do hmac(sha3-224-s390). Resultado: o algoritmo passou a ultrapassar o limite estático HASH_MAX_DESCSIZE e deixou de registrar — uma regressão real. Em números: o descsize foi de 368 para 369, enquanto o limite configurado estava abaixo; o ajuste no cabeçalho (“360 → 361”) veio exatamente para eliminar essa borda cortante. Isso encerra o bug, mas não resolve o problema de legibilidade: sem a história no commit, fica parecendo pura magia.
Nossum aproveitou para apontar a raiz de um padrão frágil no subsistema de criptografia: a dependência de um “teto” estático genérico (HASH_MAX_DESCSIZE) ganhou força quando as VLAs (Variable Length Arrays) foram banidas do kernel em 2018. Em vez de calcular o tamanho exato para cada algoritmo/implementação, muitos chamadores passaram a usar um buffer “grande o suficiente” no stack, controlado por essa constante global. Isso simplifica a vida em alguns caminhos, mas cria pegadinhas: qualquer microvariação no descsize pode estourar o teto e quebrar um algoritmo silenciosamente. Vegard sugeriu desde BUILD_BUG_ON() específicos por algoritmo a um WARN_ON() dinâmico na Crypto API, para que essas violações gritem no momento certo.
Linus concordou na essência — e reforçou a lição. Disse que a explicação deveria estar “no commit e no código”, e que “tamanhos aleatórios sem lógica” são o verdadeiro problema; VLAs foram “o caso anterior do mesmo problema”. E deixou um guia de estilo em uma frase que todo desenvolvedor do kernel poderia colar no editor: “When fixing outright bugs, at least document what went wrong and why. Not just ‘360 was too small for X, so it is now 361’.”
Por que isso importa (muito) para quem contribui
Se você participa do código aberto no kernel, este episódio é um mini-curso de “Linus Torvalds kernel development” — a filosofia prática que sustenta o projeto:
- Commit não é changelog de máquina; é narrativa técnica. Diga o que quebrou, como detectou, por que a solução funciona e por que outras não servem.
- Evite números mágicos. Se precisar deles, documente a origem e o raciocínio no comentário ao lado (ou refatore para eliminar o “mágico”).
- Previna o próximo bug. Onde couber, acrescente verificações em tempo de compilação (
BUILD_BUG_ON) ou avisos em tempo de registro (WARN_ON) para que regressões futuras não passem batido. (LKML)
E, para fechar o arco factual: sim, o pull foi aceito e a correção entrou na árvore de Linus ainda no ciclo do Linux 6.17. Mas a “bronca” pública cumpre um papel maior do que um merge: ela ajusta o termostato cultural do projeto — elevando, de tempos em tempos, a temperatura da qualidade para que o ecossistema inteiro se lembre do padrão.
