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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z-1l3mgsOi4y4N_c@boqun-archlinux>
Date: Wed, 2 Apr 2025 09:29:18 -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 Wed, Apr 02, 2025 at 11:16:27PM +0900, FUJITA Tomonori wrote:
> On Mon, 31 Mar 2025 07:03:15 -0700
> Boqun Feng <boqun.feng@...il.com> wrote:
> 
> >> My recommendation would be to take all of `rust/kernel/time` under one
> >> entry for now. I suggest the following, folding in the hrtimer entry as
> >> well:
> >> 
> >> DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST]
> >> M:	Andreas Hindborg <a.hindborg@...nel.org>
> > 
> > Given you're the one who would handle the patches, I think this make
> > more sense.
> > 
> >> R:	Boqun Feng <boqun.feng@...il.com>
> >> R:	FUJITA Tomonori <fujita.tomonori@...il.com>
> > 
> > Tomo, does this look good to you?
> 
> Fine by me.
> 
> So a single entry for all the Rust time stuff, which isn't aligned
> with C's MAINTAINERS entries. It's just for now?
> 

Given Andreas is the one who's going to handle the PRs, and he will put
all the things in one branch. I think it's fine even for long term, and
we got all relevant reviewers covered. If the Rust timekeeping + hrtimer
community expands in the future, we can also add more entries. We don't
necessarily need to copy all maintainer structures from C ;-)

> 
> >> R:	Lyude Paul <lyude@...hat.com>
> >> R:	Frederic Weisbecker <frederic@...nel.org>
> >> R:	Thomas Gleixner <tglx@...utronix.de>
> >> R:	Anna-Maria Behnsen <anna-maria@...utronix.de>
> >> R:	John Stultz <jstultz@...gle.com>
> > 
> > We should add:
> > 
> > R:      Stephen Boyd <sboyd@...nel.org>
> > 
> > If Stephen is not against it.
> > 
> >> L:	rust-for-linux@...r.kernel.org
> >> S:	Supported
> >> W:	https://rust-for-linux.com
> >> B:	https://github.com/Rust-for-Linux/linux/issues
> >> T:	git https://github.com/Rust-for-Linux/linux.git rust-timekeeping-next
> >> F:	rust/kernel/time.rs
> >> F:	rust/kernel/time/
> >> 
> >> If that is acceptable to everyone, it is very likely that I can pick 2-6
> >> for v6.16.
> >> 
> > 
> > You will need to fix something because patch 2-6 removes `Ktime` ;-)
> 
> I'll take care of it in the next version.
> 

Thanks!

> >> I assume patch 1 will go through the sched/core tree, and then Miguel
> >> can pick 7.
> >> 
> > 
> > Patch 1 & 7 probably should go together, but we can decide it later.
> 
> Since nothing has moved forward for quite a while, maybe it's time to
> drop patch 1.

No, I think we should keep it. Because otherwise we will use a macro
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?

Regards,
Boqun