From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57E7723F41D; Wed, 16 Apr 2025 12:25:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744806331; cv=none; b=T1NjmguaYa6q15qwIbfw82H3ZuyJzBeeLP0Ui0yXimUlGqUgqLUc7EmD7yIkdTd/Aa1+oAyrPWoJE6IhoS8IjJgnV0jHDASmDX6G0eI2Zf4udfA/yP+Koo/gOaPc7zcH0unvHzSA8I+0zox8hDo/QN1sjj19OO3ezESSUGAvMns= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744806331; c=relaxed/simple; bh=BV2HPhADEG6mWWoQMZcnYHZ6jfye0CvT+9anrJmNaR4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RkyfdZ21m/hNcWL98FNfPSGe2+EMWHZx44SKKgDvOSmyGC4gZLa9y/pGsxoO0iA1Tmql4YW6R6p4cBAVaEDpk3cLa3D+TEZbsP03LnHzpucXqldKpDAg6ZBwtYMGys+r53Hqjf18hXry+vnO3X9MEuq5HcUCvvI5qHx7S1kXkDI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=axsYmxZ0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="axsYmxZ0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A636C4CEE2; Wed, 16 Apr 2025 12:25:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744806330; bh=BV2HPhADEG6mWWoQMZcnYHZ6jfye0CvT+9anrJmNaR4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=axsYmxZ0s3rcoNJuk1dKe/7DUYWTK6wl0r4NiJhjwnV43VkKMkYQ/0jr1dTxFNPyv Hnqo4X1xhpvEOzx31dLj4cVDlIxR+vuI4/SCgV849cuwCaGbeOHEiPLipeB6gV5hnL fLEYgdnDg1bGj6hLfGxchmCTtOZN3k9dOXVXeG0znWQtX8EWvW8SpvabAGr1ivgRCs cMV2vKDG7KrB/1tmHmgDy3XHxegv3uKOtryNZNGk/IJST0srzyA8yyQnXXH5/YXtzf IB2w1OfdPTIilc5Bm/EV44tt6Pxn+tWP3vhZf8AFImr56KqOKgxRPcZZqRTi+yGy7s T8QDRgSsLww6A== Date: Wed, 16 Apr 2025 14:25:22 +0200 From: Danilo Krummrich To: Viresh Kumar Cc: "Rafael J. Wysocki" , Miguel Ojeda , Danilo Krummrich , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , linux-pm@vger.kernel.org, Vincent Guittot , Stephen Boyd , Nishanth Menon , rust-for-linux@vger.kernel.org, Manos Pitsidianakis , Alex =?iso-8859-1?Q?Benn=E9e?= , Joakim Bech , Rob Herring , Yury Norov , Burak Emir , Rasmus Villemoes , Russell King , linux-clk@vger.kernel.org, Michael Turquette , linux-kernel@vger.kernel.org Subject: Re: [PATCH V10 11/15] rust: cpufreq: Add initial abstractions for cpufreq framework Message-ID: References: <20250416093720.5nigxsirbvyiumcv@vireshk-i7> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250416093720.5nigxsirbvyiumcv@vireshk-i7> On Wed, Apr 16, 2025 at 03:07:20PM +0530, Viresh Kumar wrote: > On 16-04-25, 11:14, Danilo Krummrich wrote: > > On Wed, Apr 16, 2025 at 12:09:28PM +0530, Viresh Kumar wrote: > > > > + pub unsafe fn data(&self, index: usize) -> u32 { > > > + // SAFETY: By the type invariant, the pointer stored in `self` is valid and `index` is > > > + // guaranteed to be valid by the safety requirements of the function. > > > + unsafe { (*self.as_raw().add(index)).driver_data } > > > + } > > > > Those three functions above look like they're supposed to be used directly by > > drivers, but are unsafe. :( > > > > It looks like the reason for them being unsafe is that with only the pointer to > > the struct cpufreq_frequency_table array we don't know the length of the array. > > Yes. > > > However, a Table instance seems to come from TableBox, which *does* know the > > length of the KVec. Why can't we just preserve the > > length and provide a safe API? > > The Table is also created from a raw pointer, when it is received from > the C callbacks. Also the Table can be created from the OPP table, > where again we receive a raw pointer from the C code. > > I tried to do this differently earlier and finalized on current > version after some discussions on the list: > > https://lore.kernel.org/all/2025011327-cubbyhole-idealness-d4cc@gregkh/ I skimmed over your explanation from the link and got stuck at: > - The cpufreq core then calls cpufreq driver's callbacks and passes an > index to the freq-table, which the drivers don't need to verify > against table length, since the index came from the core itself. This sounds like you could just abstract the index passed through the callback in some trusted type (e.g. cpufreq::TableIndex) and let the cpufreq::Table methods take this trusted index type, rather than a raw usize, which would also make the methods safe. - Danilo