Message-Id: <DFJH89UGFFHB.318N5A8X42JOB@garyguo.net>
Date: Thu, 08 Jan 2026 20:06:12 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Gladyshev Ilya" <foxido@...ido.dev>, "Gary Guo" <gary@...yguo.net>
Cc: "foxido @ foxido . dev-cc= Rafael J. Wysocki" <rafael@...nel.org>, "Len
 Brown" <lenb@...nel.org>, "Miguel Ojeda" <ojeda@...nel.org>, "Boqun Feng"
 <boqun.feng@...il.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>,
 "Tamir Duberstein" <tamird@...il.com>, "Armin Wolf" <W_Armin@....de>,
 <platform-driver-x86@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>, <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH 2/3] rust: implement wrapper for acpi_object

On Thu Jan 8, 2026 at 5:11 PM GMT, Gladyshev Ilya wrote:
> On 1/8/26 16:21, Gary Guo wrote:
>> On Wed,  7 Jan 2026 23:35:32 +0300
>> Gladyshev Ilya <foxido@...ido.dev> wrote:
>> 
>>> ACPI Object is represented via union on C-side. On Rust side, this union
>>> is transparently wrapped for each ACPI Type, with individual methods and
>>> Defer implementation to represented type (integer, string, buffer, etc).
>>>
>>> Signed-off-by: Gladyshev Ilya <foxido@...ido.dev>
>> 
>> 
>> Hi Gladyshev,
>> 
>> I've checked the `acpi_object` implementation on the C side and it appears
>> that the buffer is not owned by the object (however managed externally,
>> could either be resting in ACPI tables directly or be allocated).
> Hm, I looked through ACPI_FREE() call sites and acpi_evaluate_object() 
> implementation, and it seems to me that the acpi_object's lifetime is 
> the same as its internal buffer.

No, it's not the same. acpi_object's lifetime needs to be shorter than
the internal buffer.

In Rust this is a typical case where you'd put lifetime on the struct
where you write

struct AcpiObject<'a> { ... }

> Overall, it is indeed managed 
> externally, but acpi_object and acpi_object::buffer->pointer live 
> together. I’m not an ACPI expert, though, so maybe I’m missing something.
>
> Anyway, the current Rust setup seems fine for now:
> 0. AcpiObject validity is guaranteed by whoever constructed/passed it (C 
> side for WMI abstractions, for example)

When you construct a `AcpiObject`; it becomes incorrect: the constructed
`AcpiObject` now can outlive the internal buffer, which is broken.

Your code indeed works fine today, but the reason is that nobody can
construct a `AcpiObject`. They can only ever receive a reference, which
makes the issue disappear, as the lifetime gets "absorbed" by the
lifetime on the reference. In essense, whenever `&'a AcpiObject` appears
in your code, it's actually meant to be `&'a AcpiObject<'a>`.

If someone were to add a Rust-side constructor for `AcpiObject`, then
the lifetime becomes broken.

So it works today, but I think it gives the wrong impression to the user
that the buffer is managed by `AcpiObject`.

Best,
Gary

> 1. You can only convert &AcpiObject to &AcpiSubType (reference to 
> reference), so AcpiSubType can't outlive AcpiObject
> 2. You can't steal the data pointer from &AcpiSubType either, because 
> the Deref impl is "logically safe" and only gives you a reference to the 
> inner data, which can't outlive AcpiSubType's reference -> can't outlive 
> AcpiObject.
>
> So for now until AcpiObject lives _less_ than it's inner data, 
> everything is OK.
>
>> Therefore, you might want to carry a lifetime to represent the lifetime of
>> underlying buffers?

Powered by blists - more mailing lists