From nobody Sat Sep 26 20:29:00 2026 Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8EE46231A3B for ; Sun, 30 Aug 2026 21:00:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788123614; cv=none; b=CUSdXLU1R6iSRNGyMet0yWciLKkgcEXsoOALpHNmW4Lmoqrnx1+23w7IwIIHmRAS5dQZA0oJ3hMBZxfsBsySdyyVhp4wq7aB2lIDms+HGB1owiIju048wPhGZTysHGIYW/j6X/EstY+2fTU6tAbkzbio/ABIHcEDFNEBjJxCvqI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788123614; c=relaxed/simple; bh=dTQd0a3FfgXA6mGn/3Gacd4vgFSrf7Cx7vyrDSL0JaI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Q3VQwnmEBh0bZmdbbobunI/9V6gqmX39Sd20LaN1UrmHLUM0VIrkx0UwAiwCf/3ymL4gHFRqSVKKOgclCwaPFUiZ3anBYHAeUXgFP+zzh/4NqRyDhHanTdB5fdc0sn5+9nJEdkj0RBsbhR2ONaG/VBgL8kSP6nSdJCgrPTSQ0rU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JsAkQBVB; arc=none smtp.client-ip=209.85.221.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JsAkQBVB" Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-5bf9506704fso1392196e0c.2 for ; Sun, 30 Aug 2026 14:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788123611; x=1788728411; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=lRAi9/lQJXt/ffKyESe5yze9eqhu+vTZPPaC1V8tycw=; b=JsAkQBVBncf+oeDPP/vq2DXcLjNDzycbcv/ifys69Y5chz2DSZI3HaJFs/0DMy420R Hqksjg5mL8URN9AWV/V4MVH2jFT9X2vbpt03e/xpKSFUqCWlBkYtLX/FCIpblhc7ubAr mmRpomHhXnEuuGW8bovDSjGe2yu/Cg0NfZxBmndDpu1tfVyQqvjHU3vD1UqS/oVUgoec 6JCaloVeZZuM06B/eDo+POAr+sFYZAV146KWEmFV4BSwhkbkP+TrDcBBymNOxj05ltrN tRGdGYuEr+/3snQ5jozU0E5kHxHZJ6P7BZrVViTAdzU3yEreCFD7L6Y43VTth1fCCwW8 30hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788123611; x=1788728411; h=content-transfer-encoding:content-type:mime-version:message-id:date :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=lRAi9/lQJXt/ffKyESe5yze9eqhu+vTZPPaC1V8tycw=; b=E87eYyeGeQNMabOOj0UEHOqGHq9tEnZF08S/dpgIj7gDbiryZttft5SYGcL1CWOzlT YWwgv10j97pTw8FW/jskOwWykdDu91v2aIJSltuUSqk2cHgqUguUuUZgYK434VM6iOL4 uoc5YcOk+uXnW8zn6/R8/GJaA634ZrEr8FPy7Cjv/D+n5X7jOyfbpAlknUhBGpiPoHoJ unkxz3qfwzxpRFOk5dGjyJqBPALQLXUSWMFBc/2gqIAp/fCd/glOhhreQInzlw2T+KCu QwiY+n2rjKWMdiaYCI8xWK1iuotgN4egVLj3ZUS4l85vJPmZI9+rdF9Z6N2PxUx+F/Xp KLlg== X-Forwarded-Encrypted: i=1; AHgh+Rr0t/dVcIHkSoH6fXmMz3deL8DOy1BVSZr5opSQwDzQ/0esRVi9MP+heNGReNXC20KrYD9DKfs6GTUk/MI=@vger.kernel.org X-Gm-Message-State: AFuF++kWn+dC6+0cXmS3U8j0h3+c/9x9NNyQEJDZotWOPnTlKKiMGx+z VENrx275zImxGGr0b1qL4JYCSPIMYjSEOshNp/pL/TtZ1WoSGKI03IpP X-Gm-Gg: AR+sD10nxixQPsdXZu5Zwny9kFCtQ1WUw0/8PiWMDNC4GGLW0asCs+TcjnhRNzWSw+H eGTEUq3UWy/iVA0EI3kAL7eiOUwzP0/YfIK0oGenCstI6t1pyHL0Giu7gd8wNw1IwsfkBmlC8yj utz60CuHKuIOHAR3Cc7lmw0xWplRiiqRrdq6R38UMWz6ZD9WTahCWGTBdTsOqQxhkPiwU4rIg9p KYgGZ78ijXKHyUtb8qXX7EYgIXhecSR3WYg97NiJ9s3o4Y+jDxdzp/ckwW/QHpYxX+Z/eOHiyWp HZF0LIbeE80H0cnRdYky6zo/tGFm29EFi787VKB6w8+5OtnZMzCVbFr9poG5O8q+hPLyvawyxH1 0CnUn2tazyaWiwAFsBMEf/XolBZuZbyITFEvB0G8sxnuarHtFSjB2GZkBwF3tZgnGGgnbIZdH6i +QWwa+9nTRZ4C7WCP5dm99vC2jEXegyqX1w7+yHT5OtBzZSziRuA2ILkz3MfOvuA== X-Received: by 2002:a05:6102:8084:b0:77a:2268:9fdb with SMTP id ada2fe7eead31-7859802053amr6135376137.7.1788123611142; Sun, 30 Aug 2026 14:00:11 -0700 (PDT) Received: from fedora ([2804:14c:daa2:8daa:6ae6:9714:ed29:7594]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-785f5a2ce07sm5448468137.6.2026.08.30.14.00.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Aug 2026 14:00:10 -0700 (PDT) From: Lucas Adryell Ramalho To: Daniel Pereira , Jonathan Corbet , Shuah Khan , Randy Dunlap Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Lucas Adryell Ramalho Subject: [PATCH] docs: translations: pt_BR: translate volatile-considered-harmful.rst Date: Sun, 30 Aug 2026 17:59:12 -0300 Message-ID: <20260830205912.478358-1-lucasadramalho@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Translate volatile-considered-harmful.rst into Brazilian Portuguese and add it to the pt_BR process documentation index. Assisted-by: ChatGPT:GPT-5.5 Signed-off-by: Lucas Adryell Ramalho --- .../translations/pt_BR/process/index.rst | 1 + .../process/volatile-considered-harmful.rst | 130 ++++++++++++++++++ 2 files changed, 131 insertions(+) create mode 100644 Documentation/translations/pt_BR/process/volatile-consi= dered-harmful.rst diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documenta= tion/translations/pt_BR/process/index.rst index eda2a3fc5..d72483720 100644 --- a/Documentation/translations/pt_BR/process/index.rst +++ b/Documentation/translations/pt_BR/process/index.rst @@ -42,6 +42,7 @@ devem estar familiarizados. Como aplicar patches Backporting e resolu=C3=A7=C3=A3o de conflitos Adicionando uma nova chamada de Sistema + Por que a classe de tipo "volatile" n=C3=A3o deve ser usada Como n=C3=A3o Deixar as ioctls malfeitas =20 Guias de pol=C3=ADticas e declara=C3=A7=C3=B5es de desenvolvedores diff --git a/Documentation/translations/pt_BR/process/volatile-considered-h= armful.rst b/Documentation/translations/pt_BR/process/volatile-considered-h= armful.rst new file mode 100644 index 000000000..b8774c0ba --- /dev/null +++ b/Documentation/translations/pt_BR/process/volatile-considered-harmful.= rst @@ -0,0 +1,130 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Por que a classe de tipo "volatile" n=C3=A3o deve ser usada +-------------------------------------------------------- + +Programadores C frequentemente interpretam volatile como uma indica=C3=A7= =C3=A3o de +que uma vari=C3=A1vel pode ser alterada fora da thread de execu=C3=A7=C3= =A3o atual; como +resultado, =C3=A0s vezes s=C3=A3o tentados a us=C3=A1-la no c=C3=B3digo do= kernel quando +estruturas de dados compartilhadas est=C3=A3o sendo utilizadas. Em outras +palavras, h=C3=A1 quem trate tipos volatile como uma esp=C3=A9cie de vari= =C3=A1vel +at=C3=B4mica simplificada, mas n=C3=A3o s=C3=A3o. O uso de volatile no c= =C3=B3digo do +kernel quase nunca =C3=A9 correto; este documento explica o porqu=C3=AA. + +O ponto-chave a entender sobre volatile =C3=A9 que seu prop=C3=B3sito =C3= =A9 suprimir +otimiza=C3=A7=C3=B5es, o que quase nunca =C3=A9 o que realmente se deseja = fazer. No kernel, +=C3=A9 necess=C3=A1rio proteger estruturas de dados compartilhadas contra = acessos +concorrentes indesejados, o que =C3=A9 uma tarefa bastante diferente. O pr= ocesso +de prote=C3=A7=C3=A3o contra concorr=C3=AAncia indesejada tamb=C3=A9m evit= a, de forma mais +eficiente, quase todos os problemas relacionados a otimiza=C3=A7=C3=B5es. + +Assim como volatile, as primitivas do kernel que tornam seguro o acesso +concorrente a dados (spinlocks, mutexes, barreiras de mem=C3=B3ria etc.) s= =C3=A3o +projetadas para evitar otimiza=C3=A7=C3=B5es indesejadas. Se forem usadas +corretamente, tamb=C3=A9m n=C3=A3o haver=C3=A1 necessidade de usar volatil= e. Se +volatile ainda for necess=C3=A1rio, quase certamente h=C3=A1 algum bug no = c=C3=B3digo. +Em c=C3=B3digo de kernel corretamente escrito, volatile s=C3=B3 serve para= deixar +as coisas mais lentas. + +Considere um bloco t=C3=ADpico de c=C3=B3digo do kernel:: + + spin_lock(&the_lock); + do_something_on(&shared_data); + do_something_else_with(&shared_data); + spin_unlock(&the_lock); + +Se todo o c=C3=B3digo seguir as regras de bloqueio, o valor de shared_data= n=C3=A3o +poder=C3=A1 mudar inesperadamente enquanto the_lock estiver mantido. Qualq= uer +outro c=C3=B3digo que queira manipular esses dados estar=C3=A1 aguardando = o bloqueio. +As primitivas de spinlock atuam como barreiras de mem=C3=B3ria (s=C3=A3o e= scritas +explicitamente para isso), o que significa que os acessos aos dados n=C3= =A3o +ser=C3=A3o otimizados de forma a atravessar essas barreiras. Assim, o comp= ilador +at=C3=A9 pode achar que sabe qual ser=C3=A1 o valor de shared_data, mas a = chamada a +spin_lock(), por atuar como barreira de mem=C3=B3ria, o for=C3=A7ar=C3=A1 = a esquecer tudo +o que sabia. N=C3=A3o haver=C3=A1 problemas de otimiza=C3=A7=C3=A3o nos ac= essos a esses dados. + +Se shared_data fosse declarada volatile, o bloqueio ainda seria +necess=C3=A1rio. No entanto, o compilador tamb=C3=A9m seria impedido de ot= imizar o +acesso a shared_data _dentro_ da se=C3=A7=C3=A3o cr=C3=ADtica, justamente = quando sabemos +que ningu=C3=A9m mais pode estar manipulando esses dados. Enquanto o bloqu= eio +estiver mantido, shared_data n=C3=A3o =C3=A9 volatile. Ao lidar com dados +compartilhados, um bloqueio adequado torna volatile desnecess=C3=A1rio e +potencialmente prejudicial. + +A classe de armazenamento volatile foi originalmente concebida para +registradores de E/S mapeados em mem=C3=B3ria. No kernel, os acessos a ess= es +registradores tamb=C3=A9m devem ser protegidos por bloqueios, mas tamb=C3= =A9m n=C3=A3o se +deseja que o compilador "otimize" esses acessos dentro de uma se=C3=A7=C3= =A3o cr=C3=ADtica. +Contudo, no kernel, os acessos =C3=A0 mem=C3=B3ria de E/S s=C3=A3o sempre = feitos por meio de +fun=C3=A7=C3=B5es de acesso; acessar diretamente a mem=C3=B3ria de E/S via= ponteiros =C3=A9 +desencorajado e n=C3=A3o funciona em todas as arquiteturas. Essas fun=C3= =A7=C3=B5es de +acesso s=C3=A3o implementadas de modo a impedir otimiza=C3=A7=C3=B5es inde= sejadas e, +portanto, mais uma vez, volatile =C3=A9 desnecess=C3=A1rio. + +Outra situa=C3=A7=C3=A3o em que se pode ser tentado a usar volatile =C3=A9= quando o +processador fica em espera ocupada pelo valor de uma vari=C3=A1vel. A forma +correta de realizar essa espera ocupada =C3=A9:: + + while (my_variable !=3D what_i_want) + cpu_relax(); + +A chamada a cpu_relax() pode reduzir o consumo de energia da CPU ou ceder +recursos a um processador l=C3=B3gico g=C3=AAmeo hyperthreaded; ela tamb= =C3=A9m atua +como barreira para o compilador e, portanto, mais uma vez, volatile =C3=A9 +desnecess=C3=A1rio. Naturalmente, a espera ocupada j=C3=A1 =C3=A9, por si = s=C3=B3, uma pr=C3=A1tica +geralmente antissocial. + +Ainda existem algumas situa=C3=A7=C3=B5es raras em que volatile faz sentid= o no +kernel: + + - As fun=C3=A7=C3=B5es de acesso mencionadas acima podem usar volatile em + arquiteturas nas quais o acesso direto =C3=A0 mem=C3=B3ria de E/S func= iona. + Essencialmente, cada chamada a uma fun=C3=A7=C3=A3o de acesso torna-se= uma + pequena se=C3=A7=C3=A3o cr=C3=ADtica por si s=C3=B3 e garante que o ac= esso ocorra conforme + esperado pelo programador. + - C=C3=B3digo assembly inline que modifica mem=C3=B3ria, mas n=C3=A3o te= m outros + efeitos colaterais vis=C3=ADveis, corre o risco de ser removido pelo G= CC. + Adicionar a palavra-chave volatile =C3=A0s instru=C3=A7=C3=B5es asm im= pede essa + remo=C3=A7=C3=A3o. + - A vari=C3=A1vel jiffies =C3=A9 especial, pois pode ter um valor difere= nte a cada + vez que =C3=A9 referenciada, mas pode ser lida sem qualquer bloqueio + especial. Portanto, jiffies pode ser volatile, mas a adi=C3=A7=C3=A3o = de + outras vari=C3=A1veis desse tipo =C3=A9 fortemente desencorajada. Nesse + sentido, jiffies =C3=A9 considerada um problema de "legado idiota" (nas + palavras de Linus); corrigi-la daria mais trabalho do que valeria a + pena. + - Ponteiros para estruturas de dados em mem=C3=B3ria coerente que possam= ser + modificadas por dispositivos de E/S podem, =C3=A0s vezes, ser + legitimamente volatile. Um buffer circular usado por um adaptador + de rede, no qual esse adaptador altera ponteiros para indicar quais + descritores j=C3=A1 foram processados, =C3=A9 um exemplo desse tipo de + situa=C3=A7=C3=A3o. + +Na maior parte do c=C3=B3digo, nenhuma das justificativas acima para o uso= de +volatile se aplica. Como resultado, o uso de volatile provavelmente +ser=C3=A1 considerado um bug e far=C3=A1 com que o c=C3=B3digo seja submet= ido a uma an=C3=A1lise +mais rigorosa. Desenvolvedores que se sintam tentados a usar volatile devem +dar um passo atr=C3=A1s e pensar no que realmente est=C3=A3o tentando alca= n=C3=A7ar. + +Patches para remover vari=C3=A1veis volatile s=C3=A3o, em geral, bem-vindo= s, desde +que venham acompanhados de uma justificativa que demonstre que as quest=C3= =B5es +de concorr=C3=AAncia foram devidamente analisadas. + + +Refer=C3=AAncias +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +[1] https://lwn.net/Articles/233481/ + +[2] https://lwn.net/Articles/233482/ + +Cr=C3=A9ditos +=3D=3D=3D=3D=3D=3D=3D=3D + +Motiva=C3=A7=C3=A3o original e pesquisa por Randy Dunlap + +Escrito por Jonathan Corbet + +Melhorias a partir de coment=C3=A1rios de Satyam Sharma, Johannes Stezenba= ch, +Jesper Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn e Stefan +Richter. --=20 2.55.0