* Re: [RFC PATCH v2] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
From: bot+bpf-ci @ 2026-05-03 16:13 UTC (permalink / raw)
To: atomlin, corbet, song, kpsingh, mattbobrowski, ast, daniel,
andrii, eddyz87, memxor, rostedt, mhiramat
Cc: skhan, jolsa, martin.lau, yonghong.song, mathieu.desnoyers,
rdunlap, atomlin, neelx, sean, chjohnst, steve, mproche,
nick.lange, linux-doc, linux-kernel, bpf, linux-trace-kernel, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260503153730.541685-1-atomlin@atomlin.com>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
> diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
[ ... ]
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 11054ad89c14..e2060c6f3e13 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -9906,6 +9906,14 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
> return err;
> }
>
> + /*
> + * Taint the kernel if the program attempts to use mutating
> + * helpers.
> + */
> + if (func_id == BPF_FUNC_probe_write_user ||
> + func_id == BPF_FUNC_override_return)
> + add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
> +
Is it possible for the kernel to be tainted here even if the program is
ultimately rejected by the verifier? check_helper_call() is executed during
the verifier's static analysis phase. If the program fails verification later
(for example, failing the GPL-compatibility check immediately following this
code, or encountering an invalid memory access), the program is safely
rejected and never loaded.
Because add_taint() synchronously modifies global state, wouldn't the kernel
remain permanently tainted in this scenario, falsely indicating a compromised
state?
Furthermore, if panic_on_taint is enabled, could a user trigger a panic merely
by attempting to load a malformed program that contains these helpers?
Could this be addressed by recording the intent to taint within the program's
auxiliary data during verification, and only invoking add_taint() once the
program has successfully passed all checks and is definitively loaded?
> /* eBPF programs must be GPL compatible to use GPL-ed functions */
> if (!env->prog->gpl_compatible && fn->gpl_only) {
> verbose(env, "cannot call GPL-restricted function from non-GPL compatible program\n");
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25283723455
^ permalink raw reply
* [PATCH v1] docs: locking: Fix stale dquot.c path
From: Costa Shulyupin @ 2026-05-03 16:02 UTC (permalink / raw)
To: Matthew Wilcox (Oracle), Jan Kara, Jonathan Corbet, Shuah Khan,
Randy Dunlap, linux-fsdevel, linux-mm, linux-doc, linux-kernel
Cc: Costa Shulyupin
The quota code was moved from fs/dquot.c to fs/quota/dquot.c
in commit 884d179dff3a ("quota: Move quota files into separate
directory"). Update the reference.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
Documentation/filesystems/locking.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
index 8421ea21bd35..277e49314d32 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -584,7 +584,7 @@ write_info: yes dqonoff_sem
FS recursion means calling ->quota_read() and ->quota_write() from superblock
operations.
-More details about quota locking can be found in fs/dquot.c.
+More details about quota locking can be found in fs/quota/dquot.c.
vm_operations_struct
====================
--
2.53.0
^ permalink raw reply related
* [PATCH v2] docs: pt_BR: translate process/license-rules.rst
From: Daniel Pereira @ 2026-05-03 16:03 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, Daniel Pereira
Translate the license-rules.rst document into Brazilian Portuguese.
This document provides guidelines on how licenses should be identified
and handled within the kernel source code.
Additionally, update the pt_BR/process/index.rst to include the new
translation in the documentation tree.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
v2:
- Fixed docutils warning: "Line block ends without a blank line" on line 72.
- Removed stray '|' character from the translation file to fix the build.
---
Documentation/translations/pt_BR/index.rst | 1 +
.../pt_BR/process/license-rules.rst | 483 ++++++++++++++++++
2 files changed, 484 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/license-rules.rst
diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 4a094d8b7..77c1a1cdc 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -67,6 +67,7 @@ kernel e sobre como ver seu trabalho integrado.
:maxdepth: 1
Introdução <process/1.Intro>
+ Regras de licenciamento <process/license-rules>
Como começar <process/howto>
Requisitos mínimos <process/changes>
Conclave (Continuidade do projeto) <process/conclave>
diff --git a/Documentation/translations/pt_BR/process/license-rules.rst b/Documentation/translations/pt_BR/process/license-rules.rst
new file mode 100644
index 000000000..1e395dfea
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/license-rules.rst
@@ -0,0 +1,483 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Regras de licenciamento do kernel Linux
+=======================================
+
+O Kernel Linux é fornecido apenas sob os termos da licença GNU General Public
+License versão 2 (GPL-2.0), conforme estabelecido em LICENSES/preferred/GPL-2.0,
+com uma exceção explícita para syscalls descrita em
+LICENSES/exceptions/Linux-syscall-note, conforme descrito no arquivo COPYING.
+
+Este arquivo de documentação fornece uma descrição de como cada arquivo-fonte
+deve ser anotado para tornar sua licença clara e inequívoca. Ele não substitui
+a licença do Kernel.
+
+A licença descrita no arquivo COPYING aplica-se ao código-fonte do kernel como
+um todo, embora arquivos-fonte individuais possam ter uma licença diferente, a
+qual deve ser obrigatoriamente compatível com a GPL-2.0::
+
+ GPL-1.0+ : GNU General Public License v1.0 ou posterior
+ GPL-2.0+ : GNU General Public License v2.0 ou posterior
+ LGPL-2.0 : GNU Library General Public License v2 apenas
+ LGPL-2.0+ : GNU Library General Public License v2 ou posterior
+ LGPL-2.1 : GNU Lesser General Public License v2.1 apenas
+ LGPL-2.1+ : GNU Lesser General Public License v2.1 ou posterior
+
+Além disso, arquivos individuais podem ser fornecidos sob uma licença dupla
+(dual license), por exemplo, uma das variantes GPL compatíveis e,
+alternativamente, sob uma licença permissiva como BSD, MIT, etc.
+
+Os arquivos de cabeçalho da API do espaço do usuário (UAPI), que descrevem a
+interface dos programas do espaço do usuário com o kernel, são um caso especial.
+De acordo com a nota no arquivo COPYING do kernel, a interface de syscall é um
+limite claro, que não estende os requisitos da GPL a qualquer software que a
+utilize para se comunicar com o kernel. Como os cabeçalhos UAPI devem ser
+passíveis de inclusão em quaisquer arquivos-fonte que criem um executável
+executado no kernel Linux, a exceção deve ser documentada por uma expressão de
+licença especial.
+
+A forma comum de expressar a licença de um arquivo-fonte é adicionar o texto
+padrão (boilerplate) correspondente no comentário inicial do arquivo. Devido a
+variações de formatação, erros de digitação, etc., esses "textos padrão" são
+difíceis de validar por ferramentas usadas no contexto de conformidade de
+licença.
+
+Uma alternativa aos textos padrão é o uso de identificadores de licença
+Software Package Data Exchange (SPDX) em cada arquivo-fonte. Os identificadores
+de licença SPDX são abreviações precisas e analisáveis por máquina para a
+licença sob a qual o conteúdo do arquivo é contribuído. Os identificadores de
+licença SPDX são gerenciados pelo Grupo de Trabalho SPDX na Linux Foundation e
+foram acordados por parceiros em toda a indústria, fornecedores de ferramentas
+e equipes jurídicas. Para mais informações, consulte https://spdx.org/
+
+O kernel Linux exige o identificador SPDX preciso em todos os arquivos-fonte.
+Os identificadores válidos usados no kernel são explicados na seção
+`Identificadores de Licença`_ e foram obtidos da lista de licenças
+oficial do SPDX em https://spdx.org/licenses/ junto com os textos das licenças.
+
+Sintaxe do identificador de licença
+-----------------------------------
+
+1. Posicionamento:
+
+ O identificador de licença SPDX em arquivos do kernel deve ser adicionado na
+ primeira linha possível do arquivo que possa conter um comentário. Para a
+ maioria dos arquivos, esta é a primeira linha, exceto para scripts que
+ requerem o '#!CAMINHO_PARA_INTERPRETADOR' na primeira linha. Para esses
+ scripts, o identificador de licença SPDX deve ser colocado na segunda linha.
+
+ A linha do identificador de licença pode então ser seguida por uma ou
+ múltiplas linhas de SPDX-FileCopyrightText, se desejado.
+
+2. Estilo:
+
+ O identificador de licença SPDX é adicionado na forma de um comentário. O
+ estilo do comentário depende do tipo de arquivo::
+
+ Fonte C: // SPDX-License-Identifier: <Expressão de Licença SPDX>
+ Cabeçalho C:/* SPDX-License-Identifier: <Expressão de Licença SPDX> */
+ ASM: /* SPDX-License-Identifier: <Expressão de Licença SPDX> */
+ scripts: # SPDX-License-Identifier: <Expressão de Licença SPDX>
+ .rst: .. SPDX-License-Identifier: <Expressão de Licença SPDX>
+ .dts{i}: // SPDX-License-Identifier: <Expressão de Licença SPDX>
+
+ Se uma ferramenta específica não conseguir lidar com o estilo de comentário
+ padrão, então deve ser utilizado o mecanismo de comentário apropriado que a
+ ferramenta aceite. Este é o motivo para ter o comentário no estilo ``/* */``
+ em arquivos de cabeçalho C. Foi observada uma quebra de build com arquivos
+ .lds gerados, onde o 'ld' falhou ao analisar o comentário C++. Isso já foi
+ corrigido, mas ainda existem ferramentas de assembler mais antigas que não
+ conseguem lidar com comentários no estilo C++.
+
+3. Sintaxe:
+
+ Uma <Expressão de Licença SPDX> pode ser um identificador SPDX simplificado
+ encontrado na Lista de Licenças SPDX, ou a combinação de dois desses
+ identificadores separados por "WITH", caso uma exceção de licença se aplique.
+ Quando múltiplas licenças são aplicáveis, a expressão utiliza as palavras-chave
+ "AND" ou "OR" para separar as sub-expressões, que devem ser delimitadas
+ por parênteses "(", ")".
+
+ Para licenças como [L]GPL, utiliza-se o sufixo "+" para indicar a opção
+ 'ou posterior'::
+
+ // SPDX-License-Identifier: GPL-2.0+
+ // SPDX-License-Identifier: LGPL-2.1+
+
+ O termo "WITH" deve ser usado sempre que houver um modificador necessário
+ para a licença. Por exemplo, os arquivos UAPI do kernel Linux utilizam a
+ expressão::
+
+ // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+ // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
+
+ Outros exemplos de uso da cláusula "WITH" para exceções no kernel são::
+
+ // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
+ // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
+
+ As exceções só podem ser aplicadas a identificadores de licença específicos.
+ Os identificadores válidos estão listados nas tags do arquivo de texto de
+ cada exceção. Para detalhes, veja o ponto `Exceções`_ no capítulo
+ `Identificadores de Licença`_.
+
+ O termo "OR" deve ser usado se o arquivo possuir licenciamento duplo (dual
+ licensed) e apenas uma das licenças puder ser selecionada. Por exemplo,
+ alguns arquivos dtsi estão disponíveis sob licença dupla::
+
+ // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+
+ Exemplos de expressões para arquivos com licenciamento duplo no kernel::
+
+ // SPDX-License-Identifier: GPL-2.0 OR MIT
+ // SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+ // SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
+ // SPDX-License-Identifier: GPL-2.0 OR MPL-1.1
+ // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
+ // SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL
+
+ O termo "AND" deve ser usado se o arquivo possuir múltiplas licenças cujos
+ termos devem ser aplicados simultaneamente. Por exemplo, se um código herdado
+ de outro projeto foi incorporado ao kernel, mas os termos da licença original
+ ainda precisam ser respeitados::
+
+ // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
+
+ Outro exemplo onde ambos os conjuntos de termos devem ser cumpridos é::
+
+ // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
+
+Identificadores de Licença
+--------------------------
+
+As licenças atualmente em uso, bem como as licenças para código adicionado ao
+kernel, podem ser divididas em:
+
+4. _`Licenças preferenciais`:
+
+ Sempre que possível, estas licenças devem ser utilizadas, pois são conhecidas
+ por serem totalmente compatíveis e amplamente usadas. Estas licenças estão
+ disponíveis no diretório::
+
+ LICENSES/preferred/
+
+ na árvore de diretórios do código-fonte do kernel.
+
+ Os arquivos neste diretório contêm o texto completo da licença e as
+ `Metatags`_. Os nomes dos arquivos são idênticos ao identificador de licença
+ SPDX que deve ser utilizado para a licença nos arquivos-fonte.
+
+ Exemplos::
+
+ LICENSES/preferred/GPL-2.0
+
+ Contém o texto da licença GPL versão 2 e as metatags obrigatórias::
+
+ LICENSES/preferred/MIT
+
+ Contém o texto da licença MIT e as metatags obrigatórias.
+
+ _`Metatags`:
+
+ As seguintes metatags devem estar presentes em um arquivo de licença:
+
+ - Valid-License-Identifier:
+
+ Uma ou mais linhas que declaram quais Identificadores de Licença são válidos
+ dentro do projeto para referenciar este texto de licença específico.
+ Geralmente, trata-se de um único identificador válido, mas, por exemplo,
+ para licenças com as opções 'ou posterior' (or later), dois identificadores
+ são válidos.
+
+ - SPDX-URL:
+
+ A URL da página SPDX que contém informações adicionais relacionadas à licença.
+
+ - Usage-Guidance:
+
+ Texto livre para conselhos de uso. O texto deve incluir exemplos corretos
+ para os identificadores de licença SPDX, conforme eles devem ser colocados
+ nos arquivos-fonte de acordo com as diretrizes de
+ `Sintaxe do identificador de licença`_.
+
+ - License-Text:
+
+ Todo o texto após esta tag é tratado como o texto original da licença.
+
+ Exemplos de formato de arquivo::
+
+ Valid-License-Identifier: GPL-2.0
+ Valid-License-Identifier: GPL-2.0+
+ SPDX-URL: https://spdx.org/licenses/GPL-2.0.html
+ Usage-Guide:
+ Para usar esta licença no código-fonte, coloque um dos seguintes pares
+ SPDX tag/valor em um comentário, de acordo com as diretrizes de
+ posicionamento na documentação das regras de licenciamento.
+ Para 'GNU General Public License (GPL) version 2 only', use:
+ SPDX-License-Identifier: GPL-2.0
+ Para 'GNU General Public License (GPL) version 2 or any later version', use:
+ SPDX-License-Identifier: GPL-2.0+
+ License-Text:
+ Texto completo da licença
+
+ ::
+
+ Valid-License-Identifier: MIT
+ SPDX-URL: https://spdx.org/licenses/MIT.html
+ Usage-Guide:
+ Para usar esta licença no código-fonte, coloque o seguinte par SPDX
+ tag/valor em um comentário, de acordo com as diretrizes de
+ posicionamento na documentação das regras de licenciamento.
+ SPDX-License-Identifier: MIT
+ License-Text:
+ Texto completo da licença
+
+5. Licenças obsoletas:
+
+ Estas licenças devem ser utilizadas apenas para código já existente ou para
+ a importação de código de outros projetos. Estas licenças estão disponíveis
+ no diretório::
+
+ LICENSES/deprecated/
+
+ na árvore de fontes do kernel.
+
+ Os arquivos neste diretório contêm o texto completo da licença e as
+ `Metatags`_. Os nomes dos arquivos são idênticos ao identificador de
+ licença SPDX que deve ser utilizado para a licença nos arquivos fonte.
+
+ Exemplos::
+
+ LICENSES/deprecated/ISC
+
+ Contém o texto da licença *Internet Systems Consortium* e as metatags
+ necessárias::
+
+ LICENSES/deprecated/GPL-1.0
+
+ Contém o texto da licença GPL versão 1 e as metatags necessárias.
+
+ Metatags:
+
+ Os requisitos de metatags para "outras" licenças são idênticos aos
+ requisitos das `Licenças preferenciais`_.
+
+ Exemplo de formato de arquivo::
+
+ Valid-License-Identifier: ISC
+ SPDX-URL: https://spdx.org/licenses/ISC.html
+ Usage-Guide:
+ O uso desta licença no kernel para novos códigos é desencorajado
+ e deve ser utilizada exclusivamente para importar código de um
+ projeto já existente.
+ Para usar esta licença no código-fonte, coloque o seguinte par
+ tag/valor SPDX em um comentário, seguindo as diretrizes de
+ posicionamento na documentação das regras de licenciamento.
+ SPDX-License-Identifier: ISC
+ License-Text:
+ Texto completo da licença
+
+6. Apenas Licenciamento Duplo
+
+ Estas licenças devem ser usadas apenas para o licenciamento duplo de código
+ com outra licença, além de uma licença preferencial. Estas licenças estão
+ disponíveis no diretório::
+
+ LICENSES/dual/
+
+ No código-fonte do kernel.
+
+ Os arquivos neste diretório contêm o texto completo da licença e as
+ `Metatags`_. Os nomes dos arquivos são idênticos ao identificador de licença
+ SPDX que deve ser usado para a licença nos arquivos fonte.
+
+ Exemplos::
+
+ LICENSES/dual/MPL-1.1
+
+ Contém o texto da licença Mozilla Public License versão 1.1 e as metatags
+ necessárias::
+
+ LICENSES/dual/Apache-2.0
+
+ Contém o texto da licença Apache License versão 2.0 e as metatags
+ necessárias.
+
+ Metatags:
+
+ Os requisitos de metatags para 'outras' licenças são idênticos aos
+ requisitos das `Licenças preferenciais`_.
+
+ Exemplo de formato de arquivo::
+
+ Valid-License-Identifier: MPL-1.1
+ SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
+ Usage-Guide:
+ NÃO use. A licença MPL-1.1 não é compatível com a GPL2. Ela só pode ser
+ usada para arquivos com licenciamento duplo onde a outra licença seja
+ compatível com a GPL2.
+ Se você acabar utilizando-a, ela DEVE ser usada em conjunto com uma
+ licença compatível com a GPL2 utilizando "OR".
+ Para usar a Mozilla Public License versão 1.1, coloque o seguinte par
+ tag/valor SPDX em um comentário, de acordo com as diretrizes de
+ posicionamento na documentação das regras de licenciamento:
+ SPDX-License-Identifier: MPL-1.1
+ License-Text:
+ Texto completo da licença
+
+|
+
+7. _`Exceções`:
+
+Algumas licenças podem ser alteradas com exceções que concedem certos direitos
+ que a licença original não concede. Estas exceções estão disponíveis no
+ diretório::
+
+ LICENSES/exceptions/
+
+ no código-fonte do kernel. Os arquivos neste diretório contêm o texto completo
+ da exceção e as `Metatags de Exceção`_ necessárias.
+
+ Exemplos::
+
+ LICENSES/exceptions/Linux-syscall-note
+
+ Contém a exceção de syscall do Linux, conforme documentado no arquivo COPYING
+ do kernel Linux, que é usada para arquivos de cabeçalho UAPI.
+ ex: /\* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note \*/::
+
+ LICENSES/exceptions/GCC-exception-2.0
+
+ Contém a 'exceção de vinculação' do GCC, que permite
+ vincular qualquer binário, independente de sua licença, à versão compilada
+ de um arquivo marcado com esta exceção. Isso é necessário para criar
+ executáveis funcionais a partir de código-fonte que não seja compatível
+ com a GPL.
+
+ _`Metatags de Exceção`:
+
+ As seguintes meta tags devem estar disponíveis em um arquivo de exceção:
+
+ - SPDX-Exception-Identifier:
+
+ Um identificador de exceção que pode ser usado com identificadores de
+ licença SPDX.
+
+ - SPDX-URL:
+
+ A URL da página SPDX que contém informações adicionais relacionadas
+ à exceção.
+
+ - SPDX-Licenses:
+
+ Uma lista separada por vírgulas de identificadores de licença SPDX para os
+ quais a exceção pode ser usada.
+
+ - Usage-Guidance:
+
+ Texto de formato livre para conselhos de uso. O texto deve ser seguido por
+ exemplos corretos para os identificadores de licença SPDX, conforme devem
+ ser colocados nos arquivos fonte de acordo com as diretrizes de
+ `Sintaxe do identificador de licença`_.
+
+ - Exception-Text:
+
+ Todo o texto após esta tag é tratado como o texto original da exceção.
+
+ Exemplos de formato de arquivo::
+
+ SPDX-Exception-Identifier: Linux-syscall-note
+ SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
+ SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+
+ Usage-Guidance:
+ Esta exceção é usada em conjunto com uma das SPDX-Licenses acima para
+ marcar arquivos de cabeçalho de API do espaço do usuário (uapi), para que
+ possam ser incluídos em código de aplicativo de espaço do usuário que não
+ esteja em conformidade com a GPL.
+ Para usar esta exceção, adicione-a com a palavra-chave WITH a um dos
+ identificadores na tag SPDX-Licenses:
+ SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
+ Exception-Text:
+ Texto completo da exceção
+
+Exemplos de formato de arquivo::
+
+ SPDX-Exception-Identifier: GCC-exception-2.0
+ SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
+ SPDX-Licenses: GPL-2.0, GPL-2.0+
+ Usage-Guidance:
+ A "GCC Runtime Library exception 2.0" é usada em conjunto com uma das
+ SPDX-Licenses acima para código importado da biblioteca de tempo de
+ execução (runtime) do GCC.
+ Para usar esta exceção, adicione-a com a palavra-chave WITH a um dos
+ identificadores na tag SPDX-Licenses:
+ SPDX-License-Identifier: <SPDX-License> WITH GCC-exception-2.0
+ Exception-Text:
+ Texto completo da exceção
+
+Todos os identificadores de licença e exceções SPDX devem ter um arquivo
+correspondente nos subdiretórios LICENSES. Isso é necessário para permitir a
+verificação por ferramentas (ex: checkpatch.pl) e para que as licenças estejam
+prontas para leitura e extração diretamente da fonte, o que é recomendado por
+várias organizações de FOSS (Software Livre e de Código Aberto), como a
+`iniciativa REUSE da FSFE <https://reuse.software/>`_.
+
+_`MODULE_LICENSE`
+-----------------
+
+ Módulos carregáveis do kernel também exigem uma tag MODULE_LICENSE(). Esta tag
+ não substitui as informações adequadas de licença do código-fonte
+ (SPDX-License-Identifier), nem é de forma alguma relevante para expressar ou
+ determinar a licença exata sob a qual o código-fonte do módulo é fornecido.
+
+ O único propósito desta tag é fornecer informações suficientes ao carregador
+ de módulos do kernel e às ferramentas de espaço do usuário sobre o módulo ser
+ software livre ou proprietário.
+
+ As strings de licença válidas para MODULE_LICENSE() são::
+
+ ============================= =============================================
+ "GPL" O módulo está licenciado sob a GPL versão 2.
+ Isso não expressa nenhuma distinção entre
+ GPL-2.0-only ou GPL-2.0-or-later. A informação
+ exata da licença só pode ser determinada por
+ meio das informações de licença nos arquivos
+ fonte correspondentes.
+
+ "GPL v2" O mesmo que "GPL". Existe por razões
+ históricas.
+
+ "GPL and additional rights" Variante histórica para expressar que o fonte
+ do módulo possui licenciamento duplo sob uma
+ variante da GPL v2 e a licença MIT. Por favor,
+ não use em códigos novos.
+
+ "Dual MIT/GPL" A maneira correta de expressar que o módulo
+ possui licenciamento duplo sob uma escolha de
+ variante GPL v2 ou licença MIT.
+
+ "Dual BSD/GPL" O módulo possui licenciamento duplo sob uma
+ escolha de variante GPL v2 ou licença BSD. A
+ variante exata da licença BSD só pode ser
+ determinada por meio das informações de
+ licença nos arquivos fonte correspondentes.
+
+ "Dual MPL/GPL" O módulo possui licenciamento duplo sob uma
+ escolha de variante GPL v2 ou Mozilla Public
+ License (MPL). A variante exata da licença
+ MPL só pode ser determinada por meio das
+ informações de licença nos arquivos fonte
+ correspondentes.
+
+ "Proprietary" O módulo está sob uma licença proprietária.
+ "Proprietary" deve ser entendido apenas como
+ "A licença não é compatível com GPLv2". Esta
+ string é exclusiva para módulos de terceiros
+ não compatíveis com GPL2 e não pode ser usada
+ para módulos que tenham seu código-fonte na
+ árvore do kernel. Módulos marcados dessa forma
+ contaminam (tainting) o kernel com a flag 'P'
+ quando carregados, e o carregador de módulos
+ recusa-se a vincular tais módulos a símbolos
+ exportados com EXPORT_SYMBOL_GPL().
+ ============================= =============================================
\ No newline at end of file
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family
From: Jonathan Corbet @ 2026-05-03 15:51 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, linux-doc, Kees Cook
Cc: linux-kernel, workflows, linux-sound, rcu, linux-media, linux-mm
In-Reply-To: <df48beafcb0cc9caff40db78285113f0b1bd9b87.camel@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> On Sun, 2026-05-03 at 08:56 -0600, Jonathan Corbet wrote:
>> Manuel Ebner <manuelebner@mailbox.org> writes:
>>
>> > Update the documentation to reflect new type-aware kmalloc-family as
>> > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj()
>> > and family")
>>
>> OK, I have applied this series. While doing so, I restored the "gfp"
>> parameter in the changelog portion where it had been mistakenly removed.
>
> That's good, thanks.
> I had two more changes lined up for v5 of this series:
>
> - ptr = kmalloc(sizeof(struct foo, gfp);
> + ptr = kmalloc(sizeof(struct foo), gfp);
>
> and
>
> -The argument gfp is optional, the default value is GFP_KERNEL.
> +The argument `gfp` is optional, the default value is `GFP_KERNEL`.
>
> I don't know how to go forward with this.
> please advice
Make a new patch on top of docs-next with the additional changes you
want to do.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v4 00/10] Auto-generate maintainer profile entries
From: Jonathan Corbet @ 2026-05-03 15:49 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Albert Ou, Mauro Carvalho Chehab,
Palmer Dabbelt, Paul Walmsley
Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel, linux-riscv,
workflows, Alexandre Ghiti, Shuah Khan, Randy Dunlap,
Dan Williams
In-Reply-To: <cover.1777295258.git.mchehab+huawei@kernel.org>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> Hi Jon,
>
> This is basically the same patch series I sent during the merge
> window, rebased on the top of post 7.1-rc1 docs-next branch.
> It is tested both with and without O=DOCS.
>
> It contains just one extra trivial patch adding a missing SPDX
> header, and, on v4, I dropped two patches touching MAINTAINERS,
> as those aren't needed anymore.
>
> This patch series change the way maintainer entry profile links
> are added to the documentation. Instead of having an entry for
> each of them at an ReST file, get them from MAINTAINERS content.
>
> That should likely make easier to maintain, as there will be a single
> point to place all such profiles.
>
> The output is a per-subsystem sorted (*) series of links shown as a
> list like this:
>
> - Arm And Arm64 Soc Sub-Architectures (Common Parts)
> - Arm/Samsung S3C, S5P And Exynos Arm Architectures
> - Arm/Tesla Fsd Soc Support
> ...
> - Xfs Filesystem
>
> Please notice that the series is doing one logical change per patch.
> I could have merged some changes altogether, but I opted doing it
> in small steps to help reviews. If you prefer, feel free to merge
> maintainers_include changes on merge.
>
> There is one interesting side effect of this series: there is no
> need to add rst files containing profiles inside a TOC tree: Just
> creating the file anywhere inside Documentation and adding a P entry
> is enough. Adding them to a TOC won't hurt.
One thing I kind of dislike about these magic mechanisms is that we end
up with a single, essentially unsorted list of stuff that readers have
to go digging their way through. It would be nice if we could somehow
apply a bit of structure; as the number of these handbooks grows, our
readers would appreciate it.
Oh well, one can always hope. Meanwhile, this seems useful, I've
applied it.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family
From: Manuel Ebner @ 2026-05-03 15:47 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, linux-doc, Kees Cook
Cc: linux-kernel, workflows, linux-sound, rcu, linux-media, linux-mm
In-Reply-To: <87o6iwczjm.fsf@trenco.lwn.net>
On Sun, 2026-05-03 at 08:56 -0600, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
> > Update the documentation to reflect new type-aware kmalloc-family as
> > suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj()
> > and family")
>
> OK, I have applied this series. While doing so, I restored the "gfp"
> parameter in the changelog portion where it had been mistakenly removed.
That's good, thanks.
I had two more changes lined up for v5 of this series:
- ptr = kmalloc(sizeof(struct foo, gfp);
+ ptr = kmalloc(sizeof(struct foo), gfp);
and
-The argument gfp is optional, the default value is GFP_KERNEL.
+The argument `gfp` is optional, the default value is `GFP_KERNEL`.
I don't know how to go forward with this.
please advice
Thanks
Manuel
> Thanks,
>
> jon
^ permalink raw reply
* Re: [PATCH] docs/pt_BR: process: link maintainer-kvm-x86 in maintainer-handbooks
From: Daniel Pereira @ 2026-05-03 15:45 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc
In-Reply-To: <87jytkcz1c.fsf@trenco.lwn.net>
Jonathan Corbet <corbet@lwn.net> wrote:
>
> >Weird, I wonder why it doesn't warn about this...? In any
> >case...applied, thanks.
>
> > jon
Hi Jon,
I also found it strange that there was no warning during compilation,
which is why I went ahead and made the adjustment.
Thank you very much!
Best regards,
Daniel Pereira
^ permalink raw reply
* Re: [PATCH v2] docs: kernel-parameters: document scope of irqaffinity= parameter
From: Aaron Tomlin @ 2026-05-03 15:41 UTC (permalink / raw)
To: Jonathan Corbet
Cc: skhan, tglx, akpm, bp, rdunlap, dave.hansen, feng.tang,
pawan.kumar.gupta, dapeng1.mi, kees, elver, paulmck, lirongqing,
bhelgaas, bigeasy, linux-doc, linux-kernel
In-Reply-To: <87y0i0bk26.fsf@trenco.lwn.net>
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
On Sun, May 03, 2026 at 09:16:01AM -0600, Jonathan Corbet wrote:
> > diff --git a/Documentation/core-api/irq/managed_irq.rst b/Documentation/core-api/irq/managed_irq.rst
> > index 05e295f3c289..8e973a7d1bd1 100644
> > --- a/Documentation/core-api/irq/managed_irq.rst
> > +++ b/Documentation/core-api/irq/managed_irq.rst
> > @@ -80,9 +80,58 @@ The following examples assume a system with 8 CPUs.
> > /proc/irq/48/effective_affinity_list:0
> > /proc/irq/48/smp_affinity_list:7
> >
> > - This can be verified via the debugfs interface
> > - (/sys/kernel/debug/irq/irqs/48). The dstate field will include
> > + If the Linux kernel was built with Kconfig CONFIG_GENERIC_IRQ_DEBUGFS
> > + enabled, this can be verified via the debugfs interface (e.g.,
> > + /sys/kernel/debug/irq/irqs/48). The dstate field will include
> > IRQD_IRQ_DISABLED, IRQD_IRQ_MASKED and IRQD_MANAGED_SHUTDOWN.
> > + A managed IRQ will also include IRQD_AFFINITY_MANAGED. For example:
> > +
> > + # cat /sys/kernel/debug/irq/irqs/87
> > + handler: handle_edge_irq
> > + device: 0000:41:00.0
>
> This will not render the way you seem to expect, it should be a literal
> block. Please do build the docs and look at the results before sending
> documentation patches.
>
Hi Jon,
Acknowledged. I'll resolve the above in the next iteration.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [RFC PATCH v2] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
From: Aaron Tomlin @ 2026-05-03 15:37 UTC (permalink / raw)
To: corbet, song, kpsingh, mattbobrowski, ast, daniel, andrii,
eddyz87, memxor, rostedt, mhiramat
Cc: skhan, jolsa, martin.lau, yonghong.song, mathieu.desnoyers,
rdunlap, atomlin, neelx, sean, chjohnst, steve, mproche,
nick.lange, linux-doc, linux-kernel, bpf, linux-trace-kernel
The primary remit of the eBPF verifier is to ensure that eBPF programs
can neither crash the kernel nor corrupt memory. Nevertheless,
administrative utilities such as "bpftrace --unsafe" permit the loading
of programs that employ destructive or mutating helpers, most notably
bpf_probe_write_user() and bpf_override_return().
Since commit b28573ebfabe ("bpf: Remove bpf_probe_write_user() warning
message"), the kernel no longer issues a warning when an attempt is made to
invoke such destructive helpers.
Consequently, this patch introduces a novel kernel taint flag,
TAINT_UNSAFE_BPF ("V"). Tainting the kernel establishes a permanent and
readily auditable indicator (i.e., /proc/sys/kernel/tainted) to alert
maintainers that the kernel's execution flow or user memory may have been
compromised by an eBPF program.
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
Changes since v1 [1]:
- Moved the taint from run-time execution to load-time verification
- Added "V" flag decoding to tools/debugging/kernel-chktaint
(Randy Dunlap)
- Updated the seq command in tainted-kernels.rst to check all 21 bits
(Randy Dunlap)
- Fixed a Sphinx "Malformed table" warning by expanding the number
column boundaries in tainted-kernels.rst
[1]: https://lore.kernel.org/lkml/20260503035220.520479-1-atomlin@atomlin.com/
---
Documentation/admin-guide/tainted-kernels.rst | 56 ++++++++++---------
include/linux/panic.h | 3 +-
kernel/bpf/verifier.c | 8 +++
kernel/panic.c | 1 +
tools/debugging/kernel-chktaint | 8 +++
5 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
index 9ead927a37c0..d26a8d29808c 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -74,35 +74,36 @@ a particular type of taint. It's best to leave that to the aforementioned
script, but if you need something quick you can use this shell command to check
which bits are set::
- $ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
+ $ for i in $(seq 21); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
Table for decoding tainted state
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-=== === ====== ========================================================
-Bit Log Number Reason that got the kernel tainted
-=== === ====== ========================================================
- 0 G/P 1 proprietary module was loaded
- 1 _/F 2 module was force loaded
- 2 _/S 4 kernel running on an out of specification system
- 3 _/R 8 module was force unloaded
- 4 _/M 16 processor reported a Machine Check Exception (MCE)
- 5 _/B 32 bad page referenced or some unexpected page flags
- 6 _/U 64 taint requested by userspace application
- 7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
- 8 _/A 256 ACPI table overridden by user
- 9 _/W 512 kernel issued warning
- 10 _/C 1024 staging driver was loaded
- 11 _/I 2048 workaround for bug in platform firmware applied
- 12 _/O 4096 externally-built ("out-of-tree") module was loaded
- 13 _/E 8192 unsigned module was loaded
- 14 _/L 16384 soft lockup occurred
- 15 _/K 32768 kernel has been live patched
- 16 _/X 65536 auxiliary taint, defined for and used by distros
- 17 _/T 131072 kernel was built with the struct randomization plugin
- 18 _/N 262144 an in-kernel test has been run
- 19 _/J 524288 userspace used a mutating debug operation in fwctl
-=== === ====== ========================================================
+=== === ======= ========================================================
+Bit Log Number Reason that got the kernel tainted
+=== === ======= ========================================================
+ 0 G/P 1 proprietary module was loaded
+ 1 _/F 2 module was force loaded
+ 2 _/S 4 kernel running on an out of specification system
+ 3 _/R 8 module was force unloaded
+ 4 _/M 16 processor reported a Machine Check Exception (MCE)
+ 5 _/B 32 bad page referenced or some unexpected page flags
+ 6 _/U 64 taint requested by userspace application
+ 7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
+ 8 _/A 256 ACPI table overridden by user
+ 9 _/W 512 kernel issued warning
+ 10 _/C 1024 staging driver was loaded
+ 11 _/I 2048 workaround for bug in platform firmware applied
+ 12 _/O 4096 externally-built ("out-of-tree") module was loaded
+ 13 _/E 8192 unsigned module was loaded
+ 14 _/L 16384 soft lockup occurred
+ 15 _/K 32768 kernel has been live patched
+ 16 _/X 65536 auxiliary taint, defined for and used by distros
+ 17 _/T 131072 kernel was built with the struct randomization plugin
+ 18 _/N 262144 an in-kernel test has been run
+ 19 _/J 524288 userspace used a mutating debug operation in fwctl
+ 20 _/V 1048576 an unsafe eBPF program (mutating helper) was loaded
+=== === ======= ========================================================
Note: The character ``_`` is representing a blank in this table to make reading
easier.
@@ -189,3 +190,8 @@ More detailed explanation for tainting
19) ``J`` if userspace opened /dev/fwctl/* and performed a FWTCL_RPC_DEBUG_WRITE
to use the devices debugging features. Device debugging features could
cause the device to malfunction in undefined ways.
+
+ 20) ``V`` if an eBPF program utilising unsafe, mutating helpers (such as
+ bpf_probe_write_user() or bpf_override_return()) was loaded. These helpers
+ bypass standard eBPF safety guarantees and can alter execution flow or
+ corrupt memory.
diff --git a/include/linux/panic.h b/include/linux/panic.h
index f1dd417e54b2..8622c02c2c24 100644
--- a/include/linux/panic.h
+++ b/include/linux/panic.h
@@ -88,7 +88,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
#define TAINT_RANDSTRUCT 17
#define TAINT_TEST 18
#define TAINT_FWCTL 19
-#define TAINT_FLAGS_COUNT 20
+#define TAINT_UNSAFE_BPF 20
+#define TAINT_FLAGS_COUNT 21
#define TAINT_FLAGS_MAX ((1UL << TAINT_FLAGS_COUNT) - 1)
struct taint_flag {
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 69d75515ed3f..cf0634d8901f 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -10287,6 +10287,14 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn
return err;
}
+ /*
+ * Taint the kernel if the program attempts to use mutating
+ * helpers.
+ */
+ if (func_id == BPF_FUNC_probe_write_user ||
+ func_id == BPF_FUNC_override_return)
+ add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
+
/* eBPF programs must be GPL compatible to use GPL-ed functions */
if (!env->prog->gpl_compatible && fn->gpl_only) {
verbose(env, "cannot call GPL-restricted function from non-GPL compatible program\n");
diff --git a/kernel/panic.c b/kernel/panic.c
index 20feada5319d..1ae19bd8fc1d 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -825,6 +825,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
TAINT_FLAG(RANDSTRUCT, 'T', ' '),
TAINT_FLAG(TEST, 'N', ' '),
TAINT_FLAG(FWCTL, 'J', ' '),
+ TAINT_FLAG(UNSAFE_BPF, 'V', ' '),
};
#undef TAINT_FLAG
diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint
index e1571c04afb5..c0fbd7bcfcfd 100755
--- a/tools/debugging/kernel-chktaint
+++ b/tools/debugging/kernel-chktaint
@@ -211,6 +211,14 @@ else
addout "J"
echo " * fwctl's mutating debug interface was used (#19)"
fi
+
+T=`expr $T / 2`
+if [ `expr $T % 2` -eq 0 ]; then
+ addout " "
+else
+ addout "V"
+ echo " * an unsafe eBPF program (mutating helper) was loaded (#20)"
+fi
echo "Raw taint value as int/string: $taint/'$out'"
# report on any tainted loadable modules
--
2.51.0
^ permalink raw reply related
* Re: [RFC PATCH] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
From: Aaron Tomlin @ 2026-05-03 15:23 UTC (permalink / raw)
To: Randy Dunlap
Cc: corbet, song, kpsingh, mattbobrowski, ast, daniel, andrii,
eddyz87, memxor, rostedt, mhiramat, skhan, jolsa, martin.lau,
yonghong.song, mathieu.desnoyers, neelx, sean, chjohnst, steve,
mproche, nick.lange, linux-doc, linux-kernel, bpf,
linux-trace-kernel
In-Reply-To: <e456f0f0-5e49-4de4-9184-32ebc53cd0a1@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
On Sat, May 02, 2026 at 09:29:27PM -0700, Randy Dunlap wrote:
> > + 20) ``V`` if an eBPF program utilising unsafe, mutating helpers (such as
> > + bpf_probe_write_user() or bpf_override_return()) was loaded. These helpers
> > + bypass standard eBPF safety guarantees and can alter execution flow or
> > + corrupt memory.
>
> (If this patch goes forward:)
>
> In this same file (above), there is a little script around line 77 where
> it should be changed:
> s/20/21/
>
> Also please update tools/debugging/kernel-chktaint for this taint flag.
>
Hi Randy,
Acknowledged. I'll address the above within the next iteration.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] bpf: introduce TAINT_UNSAFE_BPF for mutating helpers
From: Aaron Tomlin @ 2026-05-03 15:21 UTC (permalink / raw)
To: bot+bpf-ci
Cc: corbet, song, kpsingh, mattbobrowski, ast, daniel, andrii,
eddyz87, memxor, rostedt, mhiramat, skhan, jolsa, martin.lau,
yonghong.song, mathieu.desnoyers, neelx, sean, chjohnst, steve,
mproche, nick.lange, linux-doc, linux-kernel, bpf,
linux-trace-kernel, martin.lau, clm, ihor.solodrai
In-Reply-To: <78ecdb5fbbc2bba3e5d0d001c499c9011ac2e5d7dca29f60b0736c4f70c29d9f@mail.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]
On Sun, May 03, 2026 at 04:44:33AM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
> > index 9ead927a37c0..630f24996e7b 100644
> > --- a/Documentation/admin-guide/tainted-kernels.rst
> > +++ b/Documentation/admin-guide/tainted-kernels.rst
> > @@ -79,30 +79,31 @@ which bits are set::
> > Table for decoding tainted state
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > -=== === ====== ========================================================
> > -Bit Log Number Reason that got the kernel tainted
> > -=== === ====== ========================================================
>
> [ ... ]
>
> > + 19 _/J 524288 userspace used a mutating debug operation in fwctl
> > + 20 _/V 1048576 an unsafe eBPF program (mutating helper) was loaded
> > +=== === ======= ========================================================
>
> This isn't a bug, but the bottom border has 7 equals signs (=======) for
> the Number column while the top and header borders have 6 (======). Will
> this cause a Sphinx 'Malformed table' warning when rendering the
> documentation?
[ ... ]
> Earlier in the same file, around line 77, there's a shell command example
> for checking taint bits. With the addition of bit 20, shouldn't that
> command be updated from 'seq 20' to 'seq 21' so it checks all 21 bits
> (0-20)?
[ ... ]
> The current command only checks bits 0-19:
>
> $ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
>
> Since 'seq 20' produces 1..20, and the expression uses $(($i-1)), it only
> computes bit positions 0..19, missing the newly added bit 20.
Acknowledged. This will be resolved in the next iteration.
> There's a comment earlier in this file that explicitly states: "if you
> modify the taint_flags or TAINT_FLAGS_COUNT, please also modify
> tools/debugging/kernel-chktaint and
> Documentation/admin-guide/tainted-kernels.rst".
>
> While the Documentation was updated, was tools/debugging/kernel-chktaint
> also updated? The script currently processes flags 0-19 and ends with the
> J flag check. Without adding a section to check bit 20, the script won't
> decode the 'V' character in the taint string output when
> TAINT_UNSAFE_BPF is set.
>
> The script would need something like:
>
> T=`expr $T / 2`
> if [ `expr $T % 2` -eq 0 ]; then
> addout " "
> else
> addout "V"
> echo " * an unsafe eBPF program (mutating helper) was loaded (#20)"
> fi
Acknowledged. I will incorporate the suggested check for the "V" flag into
tools/debugging/kernel-chktaint.
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index a822c589c9bd..3f893d9ea764 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -183,6 +183,7 @@ unsigned int trace_call_bpf_faultable(struct trace_event_call *call, void *ctx)
> > #ifdef CONFIG_BPF_KPROBE_OVERRIDE
> > BPF_CALL_2(bpf_override_return, struct pt_regs *, regs, unsigned long, rc)
> > {
> > + add_taint(TAINT_UNSAFE_BPF, LOCKDEP_STILL_OK);
> > regs_set_return_value(regs, rc);
> > override_function_with_return(regs);
> > return 0;
>
> Since bpf_override_return is a helper invoked at runtime and can execute
> frequently on hot kprobes, will calling add_taint() here cause severe
> cache line bouncing?
>
> Looking at add_taint(), it unconditionally calls set_bit() on the global
> tainted_mask.
[ ... ]
> Also, the commit message and documentation mention the system is tainted
> when an unsafe eBPF program 'was loaded'. By applying the taint here
> during execution instead of at program load time (e.g., in the verifier),
> could this allow an unsafe BPF program to remain dormant and avoid
> detection until a specific trigger occurs?
Acknowledged. I'll move the taint application to check_helper_call().
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: watchdog: Fix typo "oncse" -> "once"
From: Jonathan Corbet @ 2026-05-03 15:21 UTC (permalink / raw)
To: Randy Dunlap, Wang Zihan, linux-watchdog
Cc: wim, linux, skhan, linux-doc, linux-kernel
In-Reply-To: <9a6393f4-6aec-4f64-b3ef-9566206c4ac7@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> On 5/2/26 4:19 AM, Wang Zihan wrote:
>> Fix a typo in mlx-wdt.rst documentation.
>>
>> Signed-off-by: Wang Zihan <3772548978@qq.com>
>> ---
>> Documentation/watchdog/mlx-wdt.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/watchdog/mlx-wdt.rst b/Documentation/watchdog/mlx-wdt.rst
>> index 35e690dea..3778f85d1 100644
>> --- a/Documentation/watchdog/mlx-wdt.rst
>> +++ b/Documentation/watchdog/mlx-wdt.rst
>> @@ -48,7 +48,7 @@ which is optional.
>> Watchdog can be started during a probe, in this case it will be
>> pinged by watchdog core before watchdog device will be opened by
>> user space application.
>> -Watchdog can be initialised in nowayout way, i.e. oncse started
>> +Watchdog can be initialised in nowayout way, i.e. once started
>> it can't be stopped.
>>
>> This mlx-wdt driver supports both HW watchdog implementations.
>
> This typo is also fixed in my 5-patch series (pending).
...which I just applied, so this patch here is no longer relevant.
Thank you, though, for working to make our documentation better!
jon
^ permalink raw reply
* Re: [PATCH 0/5] docs: watchdog: general cleaning and corrections
From: Jonathan Corbet @ 2026-05-03 15:20 UTC (permalink / raw)
To: Guenter Roeck, Randy Dunlap, linux-kernel
Cc: Shuah Khan, Wim Van Sebroeck, linux-watchdog, linux-doc
In-Reply-To: <7a5971b2-e067-40cb-8d15-aaf1926af3c3@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> On 4/30/26 15:14, Randy Dunlap wrote:
>> Hi Wim,
>>
>> On 3/22/26 5:54 PM, Randy Dunlap wrote:
>>>
>>>
>>> On 3/3/26 9:23 AM, Jonathan Corbet wrote:
>>>> Randy Dunlap <rdunlap@infradead.org> writes:
>>>>
>>>>> Fix some obvious issues in the watchdog documentation files.
>>>>> I didn't try to fix every little niggling mistake.
>>>>>
>>>>> [PATCH 1/5] docs: watchdog: mlx-wdt: small fixes
>>>>> [PATCH 2/5] docs: watchdog: pcwd: fix typo and driver info.
>>>>> [PATCH 3/5] docs: watchdog-api: general cleaning
>>>>> [PATCH 4/5] docs: watchdog-kernel-api: general cleanups
>>>>> [PATCH 5/5] docs: watchdog-parameters: add missing watchdog_core parameters
>>>>>
>>>>> Documentation/watchdog/mlx-wdt.rst | 4 -
>>>>> Documentation/watchdog/pcwd-watchdog.rst | 19 +++++--
>>>>> Documentation/watchdog/watchdog-api.rst | 38 +++++++--------
>>>>> Documentation/watchdog/watchdog-kernel-api.rst | 20 +++++--
>>>>> Documentation/watchdog/watchdog-parameters.rst | 11 +++-
>>>>> 5 files changed, 58 insertions(+), 34 deletions(-)
>>>>
>>>> Wim, do you want to pick these up, or should I take them through the
>>>> docs tree?
>>>
>>> Wim, are you active? Can you reply and/or merge these?
>>
>> What's happening with these 5 patches?
>>
>
> It looks like Wim did not send a pull request for watchdog this time around/
> Wim, are you still active, or should I send pull requests going forward ?
OK, rather than let these languish further, I've just applied them.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2] docs: kernel-parameters: document scope of irqaffinity= parameter
From: Jonathan Corbet @ 2026-05-03 15:16 UTC (permalink / raw)
To: Aaron Tomlin, skhan
Cc: tglx, akpm, bp, rdunlap, dave.hansen, feng.tang,
pawan.kumar.gupta, dapeng1.mi, kees, elver, paulmck, lirongqing,
bhelgaas, bigeasy, linux-doc, linux-kernel
In-Reply-To: <20260421150911.42404-1-atomlin@atomlin.com>
Aaron Tomlin <atomlin@atomlin.com> writes:
> There is a common misconception that the "irqaffinity=" boot parameter
> acts as a global override for all hardware interrupts. In reality, it
> only sets the irq_default_affinity mask, which is explicitly ignored
> by managed interrupts (e.g., modern multiqueue storage controllers).
>
> This patch updates kernel-parameters.txt to document this limitation,
> directs users to "isolcpus=managed_irq" and
> Documentation/core-api/irq/managed_irq.rst for further details.
> Additionally, it updates managed_irq.rst to provide a debugfs example
> demonstrating the IRQD_AFFINITY_MANAGED state flag.
>
> Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
> ---
> Changes in v1 [1]:
> - Provided an example of a managed IRQ using CONFIG_GENERIC_IRQ_DEBUGFS
> - Referenced Documentation/core-api/irq/managed_irq.rst
>
> [1]: https://lore.kernel.org/lkml/20260414200245.1153919-1-atomlin@atomlin.com/
> ---
> .../admin-guide/kernel-parameters.txt | 11 ++++
> Documentation/core-api/irq/managed_irq.rst | 53 ++++++++++++++++++-
> 2 files changed, 62 insertions(+), 2 deletions(-)
[...]
> diff --git a/Documentation/core-api/irq/managed_irq.rst b/Documentation/core-api/irq/managed_irq.rst
> index 05e295f3c289..8e973a7d1bd1 100644
> --- a/Documentation/core-api/irq/managed_irq.rst
> +++ b/Documentation/core-api/irq/managed_irq.rst
> @@ -80,9 +80,58 @@ The following examples assume a system with 8 CPUs.
> /proc/irq/48/effective_affinity_list:0
> /proc/irq/48/smp_affinity_list:7
>
> - This can be verified via the debugfs interface
> - (/sys/kernel/debug/irq/irqs/48). The dstate field will include
> + If the Linux kernel was built with Kconfig CONFIG_GENERIC_IRQ_DEBUGFS
> + enabled, this can be verified via the debugfs interface (e.g.,
> + /sys/kernel/debug/irq/irqs/48). The dstate field will include
> IRQD_IRQ_DISABLED, IRQD_IRQ_MASKED and IRQD_MANAGED_SHUTDOWN.
> + A managed IRQ will also include IRQD_AFFINITY_MANAGED. For example:
> +
> + # cat /sys/kernel/debug/irq/irqs/87
> + handler: handle_edge_irq
> + device: 0000:41:00.0
This will not render the way you seem to expect, it should be a literal
block. Please do build the docs and look at the results before sending
documentation patches.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH net-next 4/5] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
From: Andrew Lunn @ 2026-05-03 15:15 UTC (permalink / raw)
To: ciprian.regus
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, linux-kernel,
linux-doc, devicetree
In-Reply-To: <afc1cf8d-4a02-430e-89a5-b213c15a4f70@lunn.ch>
On Sun, May 03, 2026 at 05:36:13AM +0200, Andrew Lunn wrote:
> On Sun, May 03, 2026 at 02:24:53AM +0300, Ciprian Regus via B4 Relay wrote:
> > From: Ciprian Regus <ciprian.regus@analog.com>
> >
> > Add a driver for ADIN1140. The device is a 10BASE-T1S MAC-PHY
> > (integrated in the same package) that connects to a CPU over an SPI bus,
> > and implements the Open Alliance TC6 protocol for control and frame
> > transfers. As such, this driver relies on oa_tc6 for the communication
> > with the device. The device has an alternative name (AD3306), so the
> > driver can be probed using one of the two compatible strings.
> >
> > For control transactions, ADIN1140 only implements the protected mode.
> > The driver has a custom implementation for the mii_bus access methods as a
> > workaround for hardware issues:
> >
> > 1. The OA TC6 standard defines the direct and indirect access modes for
> > MDIO transactions. The ADIN1140 incorrectly advertises indirect mode
> > only (supported capabilities register - 0x2, bit 9), while actually
> > implementing just the direct mode. We cannot rely on the CAP register
> > to choose an access method (which oa_tc6 does by default, even though
> > it only implements the direct mode), so the driver has to use its
> > own.
> > 2. The ADIN1140 cannot access the C22 register space of the internal
> > PHY, while the PHY is busy receiving frames. If that happens, the
> > CONFIG0 and CONFIG2 registers of the MAC will get corrupted and the
> > data transfer will stop. Those two registers configure settings for
> > the transfer protocol between the MAC and host, so the value for some
> > of their subfields shouldn't be changed while the netdev is up.
This device is pretty broken. Has it been shipped to customers? Is
there going to be a new stepping of the silicon which is less broken?
A new device to replace this one?
Andrew
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: filesystems: cramfs: correct stale hard-link and endianness claims
From: Jonathan Corbet @ 2026-05-03 15:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: linux-doc, linux-kernel
In-Reply-To: <20260422211039.270552-1-nico@fluxnic.net>
Nicolas Pitre <nico@fluxnic.net> writes:
> Two paragraphs in cramfs.rst have been misleading for a long time:
>
> - "Hard links are supported, but hard linked files will still have
> a link count of 1": mkcramfs does not preserve hard links; it
> deduplicates by content (eliminate_doubles()). Two names for
> the same on-disk inode in the source tree become two separate
> (content-shared) entries in the image, and cramfs always reports
> a link count of 1.
>
> - "Currently, cramfs must be written and read with architectures of
> the same endianness ... PAGE_SIZE == 4096 ... is a bug, but it
> hasn't been decided what the best fix is": the endianness
> situation has been settled for years -- the kernel checks for
> CRAMFS_MAGIC_WEND in cramfs_fill_super() and refuses the mount,
> and mkcramfs has gained -B / -L for producing images of the
> opposite endianness from the build host (useful for cross-builds,
> but the reader still needs to match). Restate this accurately.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> Documentation/filesystems/cramfs.rst | 22 ++++++++++++++--------
> 1 file changed, 14 insertions(+), 8 deletions(-)
I've applied both patches, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2] Documentation/rv: Replace stale website link
From: Jonathan Corbet @ 2026-05-03 15:11 UTC (permalink / raw)
To: Gabriele Monaco, rdunlap, Steven Rostedt, Gabriele Monaco,
linux-trace-kernel, linux-doc, linux-kernel
Cc: matteo.martelli, skhan
In-Reply-To: <20260427131709.170505-2-gmonaco@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> The sched monitor page was linking to Daniel's website which is now
> down. The main purpose of the link was to point to a source for the
> models from the original author and that can be found also in his
> published paper.
>
> Replace the link with a reference to Daniel's "A thread synchronization
> model for the PREEMPT_RT Linux kernel" which can be found online and
> includes the models definitions as well as the work behind them (not the
> original patches but since they're based on a 5.0 kernel and are mostly
> included upstream, there's little value in keeping them in the docs).
>
> Fixes: 03abeaa63c08 ("Documentation/rv: Add docs for the sched monitors")
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> ---
> V2: Add link to the PDF and fixed RST references
>
> Documentation/trace/rv/monitor_sched.rst | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Documentation/kernel-parameters: Remove "Deprecated" from isolcpus=
From: Jonathan Corbet @ 2026-05-03 15:09 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Frederic Weisbecker
Cc: LKML, Gabriele Monaco, Ingo Molnar, Marcelo Tosatti,
Marco Crivellari, Michal Hocko, Paul E . McKenney, Peter Zijlstra,
Phil Auld, Steven Rostedt, Thomas Gleixner, Valentin Schneider,
Vlastimil Babka, Waiman Long, linux-doc, Bagas Sanjaya,
Shuah Khan, John Ogness
In-Reply-To: <20260427150739.bwVmmkj2@linutronix.de>
Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes:
> The isolcpus= option has been marked as deprecated in 2017. Back then it
> was desired for the domain sub option to be configured dynamically at
> runtime instead using this boot command line which provides a static
> configuration. In the meantime this option was extended by other sub
> options which don't have runtime counterpart or it does not make sense
> to provide one.
>
> The deprecated part always referred to the default `domain' sub option
> but it was not obvious. Also the reasoning behind the deprecation is
> sort of dubious: There is nothing wrong with a static configuration if
> there is no desired to reconfigure. This is useful on systems which
> have one purpose and the CPU partition configuration is not changed for
> the entire lifetime.
>
> Remove the "Deprecated" note. Remove the part of the description which
> suggest to use cpuset.sched_load_balance and instead point to the
> documentation file which explains how to use cpusets to configure this
> at runtime.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: proc: fix minor grammar and formatting issues
From: Jonathan Corbet @ 2026-05-03 15:08 UTC (permalink / raw)
To: Myro; +Cc: linux-doc, linux-kernel, linux-fsdevel, Myro Demma
In-Reply-To: <20260428133001.11384-1-myro@myromyro.com>
Myro <mirademche@gmail.com> writes:
> From: Myro Demma <myro@myromyro.com>
>
> Fix missing "from" in "prevent <pid> being reused" and
> add spacing in vm_area_struct range notation for readability.
>
> No functional changes.
>
> Signed-off-by: Myro Demma <myro@myromyro.com>
> ---
> Documentation/filesystems/proc.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index 873761087f8d..d828006bd91c 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -118,7 +118,7 @@ PTRACE_MODE_ATTACH permissions; CAP_PERFMON capability does not grant access
> to /proc/PID/mem for other processes.
>
> Note that an open file descriptor to /proc/<pid> or to any of its
> -contained files or subdirectories does not prevent <pid> being reused
> +contained files or subdirectories does not prevent <pid> from being reused
> for some other process in the event that <pid> exits. Operations on
> open /proc/<pid> file descriptors corresponding to dead processes
> never act on any new process that the kernel may, through chance, have
> @@ -2199,7 +2199,7 @@ the process is maintaining. Example output::
> | lr-------- 1 root root 64 Jan 27 11:24 400000-41a000 -> /usr/bin/ls
>
> The name of a link represents the virtual memory bounds of a mapping, i.e.
> -vm_area_struct::vm_start-vm_area_struct::vm_end.
> +vm_area_struct::vm_start - vm_area_struct::vm_end.
>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs/pt_BR: process: link maintainer-kvm-x86 in maintainer-handbooks
From: Jonathan Corbet @ 2026-05-03 15:07 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260428180208.175472-1-danielmaraboo@gmail.com>
Daniel Pereira <danielmaraboo@gmail.com> writes:
> The Portuguese translation of maintainer-kvm-x86.rst exists in the
> directory, but it was not listed in the toctree of
> maintainer-handbooks.rst.
>
> Add the missing entry to ensure the document is properly indexed and
> reachable through the main maintainer handbook page.
>
> Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
> ---
> .../translations/pt_BR/process/maintainer-handbooks.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
> index ba36df8ee..bf7a38147 100644
> --- a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
> +++ b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst
> @@ -16,3 +16,4 @@ Conteúdos:
> maintainer-netdev
> maintainer-soc
> maintainer-soc-clean-dts
> + maintainer-kvm-x86
Weird, I wonder why it doesn't warn about this...? In any
case...applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v4 0/3] Documentation: adopt new coding style of type-aware kmalloc-family
From: Jonathan Corbet @ 2026-05-03 14:56 UTC (permalink / raw)
To: Manuel Ebner, Shuah Khan, linux-doc, Kees Cook
Cc: linux-kernel, workflows, linux-sound, rcu, linux-media, linux-mm,
Manuel Ebner
In-Reply-To: <20260429070759.309110-3-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> Update the documentation to reflect new type-aware kmalloc-family as
> suggested in commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj()
> and family")
OK, I have applied this series. While doing so, I restored the "gfp"
parameter in the changelog portion where it had been mistakenly removed.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] Documentation/scheduler: Fix duplicated word in sched-deadline
From: Jonathan Corbet @ 2026-05-03 14:51 UTC (permalink / raw)
To: Miles Krause; +Cc: Juri Lelli, linux-doc, linux-kernel, Miles Krause
In-Reply-To: <20260429222435.2041-1-mileskrause5200@gmail.com>
Miles Krause <mileskrause5200@gmail.com> writes:
> The SCHED_DEADLINE documentation has a duplicated the in the CPU
> affinity section.
>
> Remove the extra word.
>
> Signed-off-by: Miles Krause <mileskrause5200@gmail.com>
> ---
> Documentation/scheduler/sched-deadline.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst
> index 3ad93cd7b59a..9019b66f6a5b 100644
> --- a/Documentation/scheduler/sched-deadline.rst
> +++ b/Documentation/scheduler/sched-deadline.rst
> @@ -685,7 +685,7 @@ Deadline Task Scheduling
>
> Deadline tasks cannot have a cpu affinity mask smaller than the root domain they
> are created on. So, using ``sched_setaffinity(2)`` won't work. Instead, the
> - the deadline task should be created in a restricted root domain. This can be
> + deadline task should be created in a restricted root domain. This can be
> done using the cpuset controller of either cgroup v1 (deprecated) or cgroup v2.
Applied, thanks,
jon
^ permalink raw reply
* Re: [PATCH v1] docs: housekeeping: Fix struct member access in code example
From: Jonathan Corbet @ 2026-05-03 14:47 UTC (permalink / raw)
To: Costa Shulyupin, Shuah Khan, Ryan Cheevers, Costa Shulyupin,
Waiman Long, Frederic Weisbecker, linux-doc, linux-kernel
In-Reply-To: <20260501043855.980567-1-costa.shul@redhat.com>
Costa Shulyupin <costa.shul@redhat.com> writes:
> No such array housekeeping_cpumasks
>
> Fix to housekeeping.cpumasks.
>
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/core-api/housekeeping.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/core-api/housekeeping.rst b/Documentation/core-api/housekeeping.rst
> index 92c6e53cea75..ccb0a88b9cb3 100644
> --- a/Documentation/core-api/housekeeping.rst
> +++ b/Documentation/core-api/housekeeping.rst
> @@ -99,7 +99,7 @@ the same RCU read side critical section.
> A typical layout example would look like this on the update side
> (``housekeeping_update()``)::
>
> - rcu_assign_pointer(housekeeping_cpumasks[type], trial);
> + rcu_assign_pointer(housekeeping.cpumasks[type], trial);
> synchronize_rcu();
This looks actively wrong to me. I think it should be:
housekeeping_cpumask(type)
... Frederic ... ?
jon
^ permalink raw reply
* Re: [PATCH] docs: pt_BR: translate process/license-rules.rst
From: Jonathan Corbet @ 2026-05-03 14:43 UTC (permalink / raw)
To: Daniel Pereira; +Cc: linux-doc, Daniel Pereira
In-Reply-To: <20260501053046.666628-1-danielmaraboo@gmail.com>
Daniel Pereira <danielmaraboo@gmail.com> writes:
> Translate the license-rules.rst document into Brazilian Portuguese.
> This document provides guidelines on how licenses should be identified
> and handled within the kernel source code.
>
> Additionally, update the pt_BR/process/index.rst to include the new
> translation in the documentation tree.
>
> Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
> ---
> Documentation/translations/pt_BR/index.rst | 1 +
> .../pt_BR/process/license-rules.rst | 484 ++++++++++++++++++
> 2 files changed, 485 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/license-rules.rst
This patch adds a new build warning:
Documentation/translations/pt_BR/process/license-rules.rst:73: WARNING: Line block ends without a blank line. [docutils]
That is caused by...
> diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
> index 4a094d8b7..77c1a1cdc 100644
> --- a/Documentation/translations/pt_BR/index.rst
> +++ b/Documentation/translations/pt_BR/index.rst
> @@ -67,6 +67,7 @@ kernel e sobre como ver seu trabalho integrado.
> :maxdepth: 1
>
> Introdução <process/1.Intro>
> + Regras de licenciamento <process/license-rules>
> Como começar <process/howto>
> Requisitos mínimos <process/changes>
> Conclave (Continuidade do projeto) <process/conclave>
> diff --git a/Documentation/translations/pt_BR/process/license-rules.rst b/Documentation/translations/pt_BR/process/license-rules.rst
> new file mode 100644
> index 000000000..93ecc57f3
> --- /dev/null
> +++ b/Documentation/translations/pt_BR/process/license-rules.rst
> @@ -0,0 +1,484 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Regras de licenciamento do kernel Linux
> +=======================================
> +
> +O Kernel Linux é fornecido apenas sob os termos da licença GNU General Public
> +License versão 2 (GPL-2.0), conforme estabelecido em LICENSES/preferred/GPL-2.0,
> +com uma exceção explícita para syscalls descrita em
> +LICENSES/exceptions/Linux-syscall-note, conforme descrito no arquivo COPYING.
> +
> +Este arquivo de documentação fornece uma descrição de como cada arquivo-fonte
> +deve ser anotado para tornar sua licença clara e inequívoca. Ele não substitui
> +a licença do Kernel.
> +
> +A licença descrita no arquivo COPYING aplica-se ao código-fonte do kernel como
> +um todo, embora arquivos-fonte individuais possam ter uma licença diferente, a
> +qual deve ser obrigatoriamente compatível com a GPL-2.0::
> +
> + GPL-1.0+ : GNU General Public License v1.0 ou posterior
> + GPL-2.0+ : GNU General Public License v2.0 ou posterior
> + LGPL-2.0 : GNU Library General Public License v2 apenas
> + LGPL-2.0+ : GNU Library General Public License v2 ou posterior
> + LGPL-2.1 : GNU Lesser General Public License v2.1 apenas
> + LGPL-2.1+ : GNU Lesser General Public License v2.1 ou posterior
> +
> +Além disso, arquivos individuais podem ser fornecidos sob uma licença dupla
> +(dual license), por exemplo, uma das variantes GPL compatíveis e,
> +alternativamente, sob uma licença permissiva como BSD, MIT, etc.
> +
> +Os arquivos de cabeçalho da API do espaço do usuário (UAPI), que descrevem a
> +interface dos programas do espaço do usuário com o kernel, são um caso especial.
> +De acordo com a nota no arquivo COPYING do kernel, a interface de syscall é um
> +limite claro, que não estende os requisitos da GPL a qualquer software que a
> +utilize para se comunicar com o kernel. Como os cabeçalhos UAPI devem ser
> +passíveis de inclusão em quaisquer arquivos-fonte que criem um executável
> +executado no kernel Linux, a exceção deve ser documentada por uma expressão de
> +licença especial.
> +
> +A forma comum de expressar a licença de um arquivo-fonte é adicionar o texto
> +padrão (boilerplate) correspondente no comentário inicial do arquivo. Devido a
> +variações de formatação, erros de digitação, etc., esses "textos padrão" são
> +difíceis de validar por ferramentas usadas no contexto de conformidade de
> +licença.
> +
> +Uma alternativa aos textos padrão é o uso de identificadores de licença
> +Software Package Data Exchange (SPDX) em cada arquivo-fonte. Os identificadores
> +de licença SPDX são abreviações precisas e analisáveis por máquina para a
> +licença sob a qual o conteúdo do arquivo é contribuído. Os identificadores de
> +licença SPDX são gerenciados pelo Grupo de Trabalho SPDX na Linux Foundation e
> +foram acordados por parceiros em toda a indústria, fornecedores de ferramentas
> +e equipes jurídicas. Para mais informações, consulte https://spdx.org/
> +
> +O kernel Linux exige o identificador SPDX preciso em todos os arquivos-fonte.
> +Os identificadores válidos usados no kernel são explicados na seção
> +`Identificadores de Licença`_ e foram obtidos da lista de licenças
> +oficial do SPDX em https://spdx.org/licenses/ junto com os textos das licenças.
> +
> +Sintaxe do identificador de licença
> +-----------------------------------
> +
> +1. Posicionamento:
> +
> + O identificador de licença SPDX em arquivos do kernel deve ser adicionado na
> + primeira linha possível do arquivo que possa conter um comentário. Para a
> + maioria dos arquivos, esta é a primeira linha, exceto para scripts que
> + requerem o '#!CAMINHO_PARA_INTERPRETADOR' na primeira linha. Para esses
> + scripts, o identificador de licença SPDX deve ser colocado na segunda linha.
> +
> + A linha do identificador de licença pode então ser seguida por uma ou
> + múltiplas linhas de SPDX-FileCopyrightText, se desejado.
> +
> +|
...^ that character there.
Please fix and resend.
jon
^ permalink raw reply
* Re: [PATCH v4] docs/ja_JP: translate more of submitting-patches.rst
From: Jonathan Corbet @ 2026-05-03 14:38 UTC (permalink / raw)
To: Akiyoshi Kurita, linux-doc; +Cc: linux-kernel, akiyks, Akiyoshi Kurita
In-Reply-To: <20260502070143.1015416-1-weibu@redadmin.org>
Akiyoshi Kurita <weibu@redadmin.org> writes:
> Translate the "Separate your changes", "Style-check your changes",
> and "Select the recipients for your patch" sections in
> Documentation/translations/ja_JP/process/submitting-patches.rst.
>
> Keep the wording close to the English text and wrap lines to match
> the style used in the surrounding Japanese translation.
>
> Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
> ---
> v4:
> - Rebase onto docs-next
>
> .../ja_JP/process/submitting-patches.rst | 127 +++++++++++++++++-
> 1 file changed, 120 insertions(+), 7 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox