linux-kernel - Re: [PATCH v11 6/8] MAINTAINERS: rust: Add new sections for DELAY/SLEEP and TIMEKEEPING API

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z-39xtyFyLjKRxsl@Mac.home>
Date: Wed, 2 Apr 2025 20:17:26 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: a.hindborg@...nel.org, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org, netdev@...r.kernel.org,
	andrew@...n.ch, hkallweit1@...il.com, tmgross@...ch.edu,
	ojeda@...nel.org, alex.gaynor@...il.com, gary@...yguo.net,
	bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
	a.hindborg@...sung.com, aliceryhl@...gle.com,
	anna-maria@...utronix.de, frederic@...nel.org, arnd@...db.de,
	jstultz@...gle.com, sboyd@...nel.org, mingo@...hat.com,
	peterz@...radead.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	vschneid@...hat.com, tgunders@...hat.com, me@...enk.dev,
	david.laight.linux@...il.com
Subject: Re: [PATCH v11 6/8] MAINTAINERS: rust: Add new sections for
 DELAY/SLEEP and TIMEKEEPING API

On Thu, Apr 03, 2025 at 12:02:00PM +0900, FUJITA Tomonori wrote:
[...]
> >> > version of read_poll_timeout(), which is strictly worse. I'm happy to
> >> > collect patch #1 and the cpu_relax() patch of patch #7, and send an PR
> >> > to tip. Could you split them a bit:
> >> > 
> >> > * Move the Rust might_sleep() in patch #7 to patch #1 and put it at
> >> >   kernel::task, also if we EXPORT_SYMBOL(__might_sleep_precision), we
> >> >   don't need the rust_helper for it.
> >> > 
> >> > * Have a separate containing the cpu_relax() bit.
> >> > 
> >> > * Also you may want to put #[inline] at cpu_relax() and might_resched().
> >> > 
> >> > and we can start from there. Sounds good?
> >> 
> >> I can do whatever but I don't think these matters. The problem is that
> > 
> > Confused. I said I would do a PR, that means if no objection, the
> > patches will get merged. Isn't this a way to move forward? Or you're
> > against that I'm doing a PR?
> 
> I don't object to you doing a PR.
> 
> I meant that it's unclear whether we can move forward with the
> approach, as we haven't received much response from the maintainers
> and we don't know what the blockers are.
> 
> >> we haven't received a response from the scheduler maintainers for a
> >> long time. We don't even know if the implementation is actually an
> >> issue.
> >> 
> > 
> > If there's an issue, I can fix it. After all, printk confirmed that
> > ".*s" format works for this case:
> > 
> > 	https://lore.kernel.org/rust-for-linux/ZyyAsjsz05AlkOBd@pathway.suse.cz/
> > 
> > and Peter sort of confirmed he's not against the idea:
> > 
> > 	https://lore.kernel.org/rust-for-linux/20250201121613.GC8256@noisy.programming.kicks-ass.net/
> > 
> > I don't see any major issue blocking this. But of course, I'm happy to
> > resolve if there is one.
> 
> I know but this patch adds a workaround to the C code for Rust´s sake,

The workaround at C is a helper function and the original C API
still works as it should be.

> I would understand if the maintainers reject it and prefer having Rust
> work around the issue instead.
> 

The workaround at Rust means we could have a function interface but we
use a macro interface.

I say we pick the C workaround, because read_poll_timeout() is a public
API, it's worth the effect making it better.

> Anyway, let's try one more time. I'll modify the patch #1 as you
> suggested and send a new patchset.
> 

Thanks!

Regards,
Boqun

> 
> Thanks!