linux-kernel - Re: [PATCH 01/33] sched/isolation: Remove housekeeping static key

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] [day] [month] [year] [list]

Message-ID: <aMwGinpG8_RbhObl@localhost.localdomain>
Date: Thu, 18 Sep 2025 15:18:02 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>,
	Marco Crivellari <marco.crivellari@...e.com>,
	Michal Hocko <mhocko@...e.com>, Tejun Heo <tj@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vlastimil Babka <vbabka@...e.cz>, Waiman Long <longman@...hat.com>
Subject: Re: [PATCH 01/33] sched/isolation: Remove housekeeping static key

Le Mon, Sep 01, 2025 at 12:26:42PM +0200, Peter Zijlstra a écrit :
> On Fri, Aug 29, 2025 at 05:47:42PM +0200, Frederic Weisbecker wrote:
> 
> > +static inline bool housekeeping_cpu(int cpu, enum hk_type type)
> > +{
> > +	if (housekeeping_flags & BIT(type))
> > +		return housekeeping_test_cpu(cpu, type);
> > +	else
> > +		return true;
> > +}
> 
> That 'else' is superfluous.
> 
> > -static inline bool housekeeping_cpu(int cpu, enum hk_type type)
> > -{
> > -#ifdef CONFIG_CPU_ISOLATION
> > -	if (static_branch_unlikely(&housekeeping_overridden))
> > -		return housekeeping_test_cpu(cpu, type);
> > -#endif
> > -	return true;
> > -}
> >  
> >  static inline bool cpu_is_isolated(int cpu)
> >  {
> > diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> > index a4cf17b1fab0..2a6fc6fc46fb 100644
> > --- a/kernel/sched/isolation.c
> > +++ b/kernel/sched/isolation.c
> > @@ -16,19 +16,13 @@ enum hk_flags {
> >  	HK_FLAG_KERNEL_NOISE	= BIT(HK_TYPE_KERNEL_NOISE),
> >  };
> >  
> > -DEFINE_STATIC_KEY_FALSE(housekeeping_overridden);
> > -EXPORT_SYMBOL_GPL(housekeeping_overridden);
> > -
> > -struct housekeeping {
> > -	cpumask_var_t cpumasks[HK_TYPE_MAX];
> > -	unsigned long flags;
> > -};
> > -
> > -static struct housekeeping housekeeping;
> > +static cpumask_var_t housekeeping_cpumasks[HK_TYPE_MAX];
> > +unsigned long housekeeping_flags;
> > +EXPORT_SYMBOL_GPL(housekeeping_flags);
> 
> I don't particularly like exporting variables much. It means modules can
> actually change the value and things like that.

Can't say I'm confortable myself.

> 
> And while an exported static_key can be changed by modules, that's
> fixable.

Hm, ok I think I can keep it.

My only worry was that in such a situation:

    CPU 0                              CPU 1
    -----                              -----
    rcu_read_lock()                   static_key_enable(&key)
    if (static_key_unlikely(&key))    synchronize_rcu()
        do_something()
    rcu_read_unlock()

The static_key_unlikely evaluation is really part of that RCU
reader sequence block. I must count on the fact that the (un-)patched
instruction is well contained within the rcu_read_lock() / rcu_read_unlock().

I think it should be the case.

Also I see that, at least on x86, static_key_enable() eventually ends up
into sync_core() broadcast IPIs. And that followed by synchronize_rcu()
should make sure that the whole block sequence from past readers should be done.

So yes I think I can try to keep that static key.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs