linux-kernel - Re: [PATCH v3] rust: regulator: add a bare minimum regulator abstraction

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: <DA03MG3VURVI.37CBV5WEEKJSH@kernel.org>
Date: Mon, 19 May 2025 13:25:56 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Mark Brown" <broonie@...nel.org>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Daniel Almeida"
 <daniel.almeida@...labora.com>, "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" <benno.lossin@...ton.me>,
 "Andreas Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl"
 <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>, "Danilo
 Krummrich" <dakr@...nel.org>, "Boris Brezillon"
 <boris.brezillon@...labora.com>, "Sebastian Reichel"
 <sebastian.reichel@...labora.com>, "Liam Girdwood" <lgirdwood@...il.com>,
 <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v3] rust: regulator: add a bare minimum regulator
 abstraction

On Mon May 19, 2025 at 11:56 AM CEST, Mark Brown wrote:
> On Sun, May 18, 2025 at 04:04:24PM +0200, Benno Lossin wrote:
>
>> I'm not sure if I understand correctly, so I'll just try to echo it and
>> see if it's correct :)
>
>> The `enable`/`disable` functions change a refcount on the underlying
>> regulator that tracks if the regulator actually is enabled/disabled.
>> Asking the hardware to enable or disable a regulator can fail, but if we
>> already know that it is enabled, only the refcount is incremented.
>
> Yes.
>
>>     It's okay to leak this enabled-refcount, since when the regulators
>> actual refcount (so the one adjusted by `_get` & `_put`) hits zero, we
>> can also disable the regulator. So the enabled-refcount is essentially a
>> weak refcount that only does something while the regulator exists.
>
> No.  You should not leak any refcount, the per consumer refcount
> duplicates what's being done for the regulator as a whole, one should
> never be incremented or decremented without the other (but there may be
> multiple consumers to choose from).

What stops the last `regulator_put` to also call `regulator_disable` a
correct number of times?

What are the kinds of problems that one could encounter when not calling
`regulator_disable` before `regulator_put` or if `regulator_enable` was
never called to begin with?
    I'm asking, because if the answer is "memory bugs", then we'll need
to make the abstraction such that users cannot misuse the enable/disable
calls (or make those calls `unsafe`).

---
Cheers,
Benno