From: Greg KH <gregkh@linuxfoundation.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
linux-pm@vger.kernel.org,
"Vincent Guittot" <vincent.guittot@linaro.org>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH V7 03/16] rust: cpu: Add from_cpu()
Date: Wed, 15 Jan 2025 08:54:09 +0100 [thread overview]
Message-ID: <2025011537-shuffling-unpaved-121a@gregkh> (raw)
In-Reply-To: <20250115072050.72oeibi735k3pjdq@vireshk-i7>
On Wed, Jan 15, 2025 at 12:50:50PM +0530, Viresh Kumar wrote:
> On 14-01-25, 19:44, Greg KH wrote:
> > > +pub fn from_cpu(cpu: u32) -> Result<&'static Device> {
> > > + // SAFETY: The pointer returned by `get_cpu_device()`, if not `NULL`, is a valid pointer to
> > > + // a `struct device` and is never freed by the C code.
> >
> > I thought it was pointed out that it could be freed when a cpu was
> > hot-unplugged? Or is that a different device in the cpu code? We seem
> > to have 2 of them and it's not obvious which is which :(
>
> I did reply [1] to that earlier. The CPU can get unregistered but the
> memory for the device is never freed (it is part of struct cpu). Some
> calls on the CPU device may fail later on (if called for an unregisted
> dev), but should never crash the kernel.
Ah, but that's not really something that SAFETY should override, right?
Yes, you know your implementation of this will stop using the pointer in
the hotplug callback before it goes away but that's not documented here.
And having the device "fail" afterward isn't really ok either as you are
relying on the driver core to always check for this and I'm not so sure
that it always does on all codepaths.
But, I'm ok with this for now, as you are just copying the bad C model
at the moment, but it really feels like a huge foot-gun waiting to go
off. Any way to put some more documentation here as in "use this at
your own risk!"?
thanks,
greg k-h
next prev parent reply other threads:[~2025-01-15 7:54 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 11:22 [PATCH V7 00/16] Rust bindings for cpufreq and OPP core + sample driver Viresh Kumar
2025-01-13 11:22 ` [PATCH V7 01/16] cpufreq: Use enum for cpufreq flags that use BIT() Viresh Kumar
2025-01-13 11:22 ` [PATCH V7 02/16] PM / OPP: Add reference counting helpers for Rust implementation Viresh Kumar
2025-01-13 11:22 ` [PATCH V7 03/16] rust: cpu: Add from_cpu() Viresh Kumar
2025-01-14 18:44 ` Greg KH
2025-01-15 7:20 ` Viresh Kumar
2025-01-15 7:54 ` Greg KH [this message]
2025-01-15 7:58 ` Viresh Kumar
2025-01-15 8:09 ` Greg KH
2025-01-16 9:17 ` Viresh Kumar
2025-01-15 8:10 ` Alice Ryhl
2025-01-15 8:33 ` Viresh Kumar
2025-01-13 11:22 ` [PATCH V7 04/16] rust: device: Add property_present() Viresh Kumar
2025-01-14 18:42 ` Greg Kroah-Hartman
2025-01-14 18:42 ` Greg Kroah-Hartman
2025-01-15 7:15 ` Viresh Kumar
2025-01-15 7:35 ` Viresh Kumar
2025-01-15 17:21 ` Greg Kroah-Hartman
2025-01-13 11:23 ` [PATCH V7 05/16] rust: Add cpumask helpers Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 06/16] rust: Add bindings for cpumask Viresh Kumar
2025-01-22 14:40 ` Miguel Ojeda
2025-01-23 3:43 ` Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 07/16] rust: Add bare minimal bindings for clk framework Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 08/16] rust: Add initial bindings for OPP framework Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 09/16] rust: Extend OPP bindings for the OPP table Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 10/16] rust: Extend OPP bindings for the configuration options Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 11/16] rust: Add initial bindings for cpufreq framework Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 12/16] rust: Extend cpufreq bindings for policy and driver ops Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 13/16] rust: Extend cpufreq bindings for driver registration Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 14/16] rust: Extend OPP bindings with CPU frequency table Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 15/16] cpufreq: Add Rust based cpufreq-dt driver Viresh Kumar
2025-01-13 11:23 ` [PATCH V7 16/16] DO-NOT_MERGE: cpufreq: Rename cpufreq-dt platdev Viresh Kumar
2025-01-22 13:18 ` [PATCH] rust: macros: enable use of hyphens in module names Anisse Astier
2025-01-22 13:39 ` [PATCH v2] " Anisse Astier
2025-01-22 14:38 ` Viresh Kumar
2025-01-30 4:58 ` Viresh Kumar
2025-01-30 6:08 ` Anisse Astier
2025-01-30 11:51 ` Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025011537-shuffling-unpaved-121a@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox