linux-kernel - Re: [PATCH RFC srcu] Expedite srcu_schedule_cbs

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: <5b683054-084a-fae7-0bc6-8db28f0860c3@arm.com>
Date:   Tue, 18 Apr 2017 18:43:05 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     paulmck@...ux.vnet.ibm.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC srcu] Expedite srcu_schedule_cbs_snp() callback
 invocation

On 18/04/17 18:33, Paul E. McKenney wrote:
> Although Tree SRCU does reduce delays when there is at least one
> synchronize_srcu_expedited() invocation pending, srcu_schedule_cbs_snp()
> still waits for SRCU_INTERVAL before invoking callbacks.  Since
> synchronize_srcu_expedited() now posts a callback and waits for
> that callback to do a wakeup, this destroys the expedited nature of
> synchronize_srcu_expedited().
> 
> This commit therefore invokes callbacks immediately at the end of the
> grace period when there is at least one synchronize_srcu_expedited()
> invocation pending.
> 
> Reported-by: Marc Zyngier <marc.zyngier@....com>
> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> 
> diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> index 1e54f91c2ff7..744ffdb79d23 100644
> --- a/kernel/rcu/srcutree.c
> +++ b/kernel/rcu/srcutree.c
> @@ -447,7 +447,8 @@ static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp)
>  	int cpu;
>  
>  	for (cpu = snp->grplo; cpu <= snp->grphi; cpu++)
> -		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu), SRCU_INTERVAL);
> +		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu),
> +				      atomic_read(&sp->srcu_exp_cnt) ? 0 : SRCU_INTERVAL);
>  }
>  
>  /*

This fixes the issue I was observing, where UEFI in a KVM guest would
take a x8 slowdown while it messes with some NOR flash emulation on
arm64 (don't ask, this is horrible...). Anyway:

Tested-by: Marc Zyngier <marc.zyngier@....com>

Thanks again Paul!

	M.
-- 
Jazz is not dead. It just smells funny...