linux-kernel - Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones

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]

Date:	Thu, 2 Jul 2015 12:23:31 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>, josh@...htriplett.org,
	linux-kernel@...r.kernel.org, Lai Jiangshan <laijs@...fujitsu.com>,
	dipankar@...ibm.com, Andrew Morton <akpm@...ux-foundation.org>,
	tglx@...utronix.de, rostedt <rostedt@...dmis.org>,
	dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
	fweisbec@...il.com, oleg@...hat.com,
	bobby prani <bobby.prani@...il.com>
Subject: Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging
 normal ones

On Thu, Jul 02, 2015 at 06:47:47PM +0000, Mathieu Desnoyers wrote:
> ----- On Jul 2, 2015, at 2:35 PM, Ingo Molnar mingo@...nel.org wrote:
> 
> > * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> > 
> >> > And it's not like it's that hard to stem the flow of algorithmic sloppiness at
> >> > the source, right?
> >> 
> >> OK, first let me make sure that I understand what you are asking for:
> >> 
> >> 1.	Completely eliminate synchronize_rcu_expedited() and
> >> 	synchronize_sched_expedited(), replacing all uses with their
> >> 	unexpedited counterparts.  (Note that synchronize_srcu_expedited()
> >> 	does not wake up CPUs, courtesy of its read-side memory barriers.)
> >> 	The fast-boot guys are probably going to complain, along with
> >> 	the networking guys.
> >> 
> >> 2.	Keep synchronize_rcu_expedited() and synchronize_sched_expedited(),
> >> 	but push back hard on any new uses and question any existing uses.
> >> 
> >> 3.	Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in
> >> 	acpi_os_map_cleanup").
> >> 
> >> 4.	Something else?
> > 
> > I'd love to have 1) but 2) would be a realistic second best option? ;-)
> 
> Perhaps triggering a printk warning if use of
> synchronize_{rcu,sched}_expedited() go beyond of certain rate might be
> another option ? If we detect that a caller calls it too often, we could
> emit a printk warning with a stack trace. This should ensure everyone
> is very careful about where they use it.

My first thought is that a storm of expedited grace periods would be
most likely to show up in some error condition, and having them
splat might obscure the splats identifying the real problem.  Or did
you have something else in mind here?

							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/