linux-kernel - Re: [RFC PATCH 6/7] preempt/dynamic: Provide irqentry_exit_cond

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: <20201110134503.GC48886@lothringen>
Date:   Tue, 10 Nov 2020 14:45:03 +0100
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, Mel Gorman <mgorman@...e.de>,
        Michal Hocko <mhocko@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, Michal Hocko <mhocko@...e.com>
Subject: Re: [RFC PATCH 6/7] preempt/dynamic: Provide
 irqentry_exit_cond_resched() static call

On Tue, Nov 10, 2020 at 11:32:21AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 01:56:08AM +0100, Frederic Weisbecker wrote:
> > [convert from static key to static call, only define static call when
> > PREEMPT_DYNAMIC]
> 
> >  noinstr void irqentry_exit(struct pt_regs *regs, irqentry_state_t state)
> >  {
> > @@ -383,8 +386,13 @@ noinstr void irqentry_exit(struct pt_regs *regs, irqentry_state_t state)
> >  		}
> >  
> >  		instrumentation_begin();
> > -		if (IS_ENABLED(CONFIG_PREEMPTION))
> > +		if (IS_ENABLED(CONFIG_PREEMPTION)) {
> > +#ifdef CONFIG_PREEMT_DYNAMIC
> > +			static_call(irqentry_exit_cond_resched)();
> > +#else
> >  			irqentry_exit_cond_resched();
> > +#endif
> > +		}
> >  		/* Covers both tracing and lockdep */
> >  		trace_hardirqs_on();
> >  		instrumentation_end();
> 
> The reason I had this a static_branch() is that because if you look at
> the code-gen of this function, you'll find it will inline the call.
> 
> Not sure it matters much, but it avoids a CALL+RET.

I wouldn't mind turning it to a static key but that adds one more
requirement for the architectures that want this, namely proper
support for static key. Now probably architectures supporting
static call inline (for now only x86) will have proper static
key support as well. So this probably doesn't matter after all.

Thanks.