On Sun, Aug 30 2026 at 08:18, Boqun Feng wrote:
> On Sat, Aug 29, 2026 at 04:37:37PM -0700, Boqun Feng wrote:
>> And while we are at, we can just introduce a
>> raw_local_irq_restore_auto() (definitely needs a better name), which
>> doesn't need a cnt:
>>
>> static __always_inline void __raw_local_irq_restore_auto(void)
>> {
>> 	debug_assert((preempt_count() & HARDIRQ_DISABLE_MASK));
>> 
>> 	if (!(__preempt_count_sub_return(HARDIRQ_DISABLE_OFFSET) & HARDIRQ_DISABLE_MASK))
>> 		arch_local_irq_enable();
>> }

Can we just make the thing work in the first place?
 
>> And we can slowly convert irq_restore() users to use it?

Somewhere down the road.

> I decided to use local_irq_resume(), not sure whether it's a good name
> either...
>
> If we are OK to not fully revert on commit e901c1510e24 ("irq,spin_lock:
> Add counted interrupt disabling/enabling"), I think the following will
> resolve the 0day built errors on your irqflags branch (I rebased onto
> tip/locking/urgent with rest of your series on irqflags branch). A few
> things to notice:

The zero day failure is not due to that. It's because I reverted that
refcounted muck as well in my git tree.

I just rebased the series on top of tip locking/urgent, which only has
the irq,spinlock revert and your patches on top.

> * I haven't found a way that we can do a local_irq_resume() when
>   !CONFIG_PREEMPT_COUNT_IRQFLAGS, and if we cannot, it's going to make
>   part of Rust code depends on CONFIG_PREEMPT_COUNT_IRQFLAGS=y

That's a good thing as it might make people actually get their act
together. And you can work around that in interrupt_rc.h itself.

Can you please stop bouncing around like a rubber ball and take your
time?

First of all I want to move interrupt_rc.h and the whole spinlock muck
into rust/helpers/ now. Why?

Simply because it is Rust only and we don't want to expose any of this
stuff to random driver writers. See attached patch.

I've rebased my devel branch on top of tip/locking/urgent and applied
that patch so the robots can have their field day.

The actual PREEMPT_COUNT_IRQFLAGS thing will be 7.4 material obviously
and as this is confined to Rust then it's trivial enough to work around
it locally without exposing more stuff. See tiny delta patch below.

So the only side effect of that is that the Rust implementation will not
be fully integrated into the preempt count magic, but it should just
work, no?

And when an architecture supports the real thing then it gets all the
benefits with bells and whistels.

I really want to get the PREEMPT_COUNT_IRQFLAGS design right first and
then we can think about simplifications and cleanups and remove the
whole Rust magic once all architectures which support Rust play along.

Thanks,

        tglx

---
 rust/helpers/interrupt_rc.h |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/rust/helpers/interrupt_rc.h
+++ b/rust/helpers/interrupt_rc.h
@@ -38,8 +38,14 @@ extern void _local_interrupt_save_state(
 extern void _local_interrupt_enable(void);
 #endif
 
+#ifdef CONFIG_PREEMPT_COUNT_IRQFLAGS
 #define hardirq_disable_enter()	__preempt_count_add_return(HARDIRQ_DISABLE_OFFSET)
 #define hardirq_disable_exit()	__preempt_count_sub_return(HARDIRQ_DISABLE_OFFSET)
+#else
+DECLARE_PER_CPU(unsigned int, local_interrupt_cnt);
+#define hardirq_disable_enter()	__this_cpu_add_return(local_interrupt_count, HARDIRQ_DISABLE_OFFSET)
+#define hardirq_disable_exit()	__this_cpu_sub_return(local_interrupt_count, HARDIRQ_DISABLE_OFFSET)
+#endif
 
 static inline void local_interrupt_disable(void)
 {