linux-kernel - Re: How do I increment a per-CPU variable without warning?

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: <20140416035419.GA30105@linux.vnet.ibm.com>
Date:	Tue, 15 Apr 2014 20:54:19 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Dave Jones <davej@...hat.com>, cl@...ux.com,
	linux-kernel@...r.kernel.org, mingo@...nel.org, tj@...nel.org,
	grygorii.strashko@...com, peterz@...radead.org
Subject: Re: How do I increment a per-CPU variable without warning?

On Tue, Apr 15, 2014 at 03:47:26PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 15, 2014 at 06:29:51PM -0400, Dave Jones wrote:
> > On Tue, Apr 15, 2014 at 03:17:55PM -0700, Paul E. McKenney wrote:
> > 
> >  > My current admittedly crude workaround is as follows:
> >  > 
> >  > 	static inline bool rcu_should_resched(void)
> >  > 	{
> >  > 		int t;
> >  > 
> >  > 	#ifdef CONFIG_DEBUG_PREEMPT
> >  > 		preempt_disable();
> >  > 	#endif /* #ifdef CONFIG_DEBUG_PREEMPT */
> >  > 		t = __this_cpu_read(rcu_cond_resched_count) + 1;
> >  > 		if (t < RCU_COND_RESCHED_LIM) {
> >  > 			__this_cpu_write(rcu_cond_resched_count, t);
> >  > 	#ifdef CONFIG_DEBUG_PREEMPT
> >  > 			preempt_enable();
> >  > 	#endif /* #ifdef CONFIG_DEBUG_PREEMPT */
> >  > 			return false;
> >  > 		}
> >  > 	#ifdef CONFIG_DEBUG_PREEMPT
> >  > 		preempt_enable();
> >  > 	#endif /* #ifdef CONFIG_DEBUG_PREEMPT */
> >  > 		return true;
> >  > 	}
> > 
> > Won't using DEBUG_PREEMPT instead of just CONFIG_PREEMPT here make this
> > silently do the wrong thing if preemption is enabled, but debugging isn't ?
> 
> If preemption is enabled, but debugging is not, then yes, the above code
> might force an unnecessary schedule() if the above code was preempted
> between the __this_cpu_read() and the __this_cpu_write().  Which does
> not cause a problem, especially given that it won't happen very often.
> 
> > I'm not seeing why you need the ifdefs at all, unless the implied
> > barrier() is a problem ?
> 
> I don't think that Peter Zijlstra would be too happy about an extra
> unneeded preempt_disable()/preempt_enable() pair in the cond_resched()
> fastpath.  Not that I necessarily expect him to be particularly happy
> with the above, but perhaps someone has a better approach.

But falling back on the old ways of doing this at least looks a bit
nicer:

	static inline bool rcu_should_resched(void)
	{
		int t;
		int *tp = &per_cpu(rcu_cond_resched_count, raw_smp_processor_id());

		t = ACCESS_ONCE(*tp) + 1;
		if (t < RCU_COND_RESCHED_LIM) {
			ACCESS_ONCE(*tp) = t;
			return false;
		}
		return true;
	}

Other thoughts?

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/