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: <1318523526.27731.18.camel@twins>
Date:	Thu, 13 Oct 2011 18:32:05 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jason Baron <jbaron@...hat.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"David S. Miller" <davem@...emloft.net>,
	David Daney <david.daney@...ium.com>,
	Michael Ellerman <michael@...erman.id.au>,
	Jan Glauber <jang@...ux.vnet.ibm.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Xen Devel <xen-devel@...ts.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	rth@...hat.com
Subject: Re: [PATCH RFC V4 06/10] jump_label: add
 arch_jump_label_transform_static() to optimise non-live code updates

On Thu, 2011-10-13 at 11:55 -0400, Jason Baron wrote:
> > I actually need them to be either way.. no preference between on or off
> > just a means of very _very_ infrequent runtime change in behaviour.
> > 
> 
> ok, this is a new use case, all the current users are biased with gcc
> out-of-lining the infrequent case.

Right, 

> > If we can push jump_label init to before sched_init() all I need is a
> > static_branch() without the unlikely() in to avoid GCC out-of-lining the
> > branch.
> > 
> 
> hmmm....the current code (I believe) is biased  b/c gcc sees the
> branch as always false, see: arch_static_branch() - its not b/c we have
> an unlikely there. Without open coding the label, like we had before
> everybody hated, I'll have to play around and see what will create an
> unbiased branch...perhaps, somebody has an idea? 

Fix gcc and stick an unlikely in static_branch() ? :-)

> > > and by patching them early
> > > like this, at least for x86, we can avoid the stop machine calls. So its
> > > the combination of most are expected to be off and no sense to call extra
> > > stop machines that lead the code to its present state.
> > 
> > But we could use arch_jump_label_transform_static because its before we
> > actually execute any module text (sans the arg crap) which is
> > stomp-machine free, removing that obstacle.
> > 
> > Or am I confused more?
> > 
> 
> The MODULE_COMING callback happens *after* the call to flush_module_icache(mod),
> so I'm not sure that is safe... 

We can issue another one of those?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ