linux-kernel - Re: [PATCH] Introduce Tyr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72kYP5WcrFNhdAuJ_mK6s4kuBoJp3E_88HrXU4zfcb5UzQ@mail.gmail.com>
Date: Mon, 30 Jun 2025 19:29:29 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Daniel Almeida <daniel.almeida@...labora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Daniel Stone <daniels@...labora.com>, Rob Herring <robh@...nel.org>, 
	Alice Ryhl <alice.ryhl@...gle.com>, Beata Michalska <beata.michalska@....com>, 
	Carsten Haitzler <carsten.haitzler@...s.arm.com>, 
	Boris Brezillon <boris.brezillon@...labora.com>, Ashley Smith <ashley.smith@...labora.com>, 
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	rust-for-linux@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH] Introduce Tyr

On Mon, Jun 30, 2025 at 5:23 PM Daniel Almeida
<daniel.almeida@...labora.com> wrote:
>
> When I said "in development"I was referring to "dead_code" specifically, as we
> will invariably have some of that until the other parts of the driver land.
>
> Just as an example: IMHO it doesn't make much sense to only introduce the
> register definitions used for this patch if we know for sure that:
>
> a) the currently unused definitions will be used once the subsequent parts land,
>
> b) they will not change, as they're derived from the hardware itself
>
> It makes more sense to just sit down and transcribe this part of the spec at
> once. It lowers the chance of copy and paste errors too.
>
> As I said, I was unfamiliar with "expect". Can it be made to work on a module
> level? Anyway, I can try to make this work with "expect" instead of “allow", no
> worries :)

Hmm... I am not sure what you are trying to say -- using `expect`
should just generally be as simple as changing the word from `allow`.
`expect` works like `allow`, except it will complain if the lint does
not trigger. It is essentially just that. And, yeah, it works on
modules.

In particular, it should not change how you decide anything else. In
other words, it is not about avoiding `dead_code`, but rather about
using a better `allow(dead_code)`.

Sometimes `allow` is simpler, e.g. when triggering a lint depends on
the kernel configuration or other reasons, in which case using `allow`
is just fine (please see the docs I linked). But I don't think you are
in those cases (e.g. I don't see conditional compilation, at least in
the patch above), so that is why I suggested it.

I hope that clarifies.

Cheers,
Miguel