linux-kernel - Re: [PATCH 0/4] jump label patches

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: <20091007001436.B5FE9A8C@magilla.sf.frob.com>
Date:	Tue,  6 Oct 2009 17:14:36 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Richard Henderson <rth@...hat.com>
Cc:	Jason Baron <jbaron@...hat.com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, mathieu.desnoyers@...ymtl.ca, tglx@...utronix.de,
	rostedt@...dmis.org, ak@...e.de, mhiramat@...hat.com
Subject: Re: [PATCH 0/4] jump label patches

> At present, the asm goto extension gives no prediction weights to any 
> path.  I had hoped that the -freorder-blocks pass (enabled with -O2) 
> would automatically place the relevant fallthrough blocks immediately 
> after the asm goto.  It did happen for small test cases, but a message 
> from Jason downthread indicates that it doesn't always happen.

Kernel builds usually use -Os.  Is there anything else we can do now (4.4)
to influence this placement (while keeping the unlikely target block inside
a scope, i.e. macro, with the asm goto)?

Also note that another usage pattern I'm considering for the general case
would (via fancy macros) look something like:

	if (({ __label__ yes; int maybe = 0;
	      asm goto ("jmp %l[yes]" ::: yes);
	      if (0) yes: maybe = 1;
	      maybe; }))
	  doit();
	else
	  dontit();

So please also advise on making something of that character come out optimal.

> > 	if (__builtin_expect(0,0)) do_trace: __attribute__((cold)) { ... }
> 
> An attribute cold on a label is something that I've suggested, but have 
> not yet implemented.  I think that might be the easiest way to add 
> prediction weights to an asm goto.

Ok.  That syntax is accepted already now (4.4.1 anyway) but always generates:
	warning: ?cold? attribute ignored
so it would be annoying to start using it now before compiler-version
conditionals for a version where it does at most nothing.

Btw, if you do make that work I think it would be nice (and seems like it
would be not much different internally) to make:
	label:  __attribute__ ((cold, section (".text.lukewarm")))
work too.  I can see this being used for a few different kinds of things,
where a specialized user like the kernel might want to segregate multiple
different kinds of text.  e.g., "really cold" for rare exception stuff,
"tracepoint warm" for stuff that's cold by default but actually hot if
lots of tracing is enabled, etc.


Thanks,
Roland
--
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/