linux-kernel - Re: [RFC] gcc feature request: Moving blocks into sections

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:	Mon, 05 Aug 2013 15:39:23 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, gcc <gcc@....gnu.org>,
	Ingo Molnar <mingo@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	David Daney <ddaney.cavm@...il.com>,
	Behan Webster <behanw@...verseincode.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:39 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > I had patches that did exactly this:
> >
> >  https://lkml.org/lkml/2012/3/8/461
> >
> > But it got dropped for some reason. I don't remember why. Maybe because
> > of the complexity?
> 
> Ugh. Why the crazy update_jump_label script stuff? I'd go "Eww" at
> that too, it looks crazy. The assembler already knows to make short
> 2-byte "jmp" instructions for near jumps, and you can just look at the
> opcode itself to determine size, why is all that other stuff required?

Hmm, I probably added that "optimization" in there because I was doing a
bunch of jump label work and just included it in. It's been over a year
since I've worked on this so I don't remember all the details. That
update_jump_label program may have just been to do the conversion of
nops at compile time and not during boot. It may not be needed. Also, it
was based on the record-mcount code that the function tracer uses, which
is also done at compile time, to get all the mcount locations.

> 
> IOW, 5/7 looks sane, but 4/7 makes me go "there's something wrong with
> that series".

I just quickly looked at the changes again. I think I can redo them and
send them again for 3.12. What do you think about keeping all but patch
4?

1 - Use a default nop at boot. I had help from hpa on this. Currently,
    jump labels use a jmp instead of a nop on boot.

2 - On boot, the jump label nops (jump before patch 1) looks at the best
    run time nop, and converts them. Since it is likely that the current
    nop is already ideal, skip the conversion. Again, this is just a
    boot up optimization.

3 - Add a test to see what we are converting. Adds safety checks like
there
    is in the function tracer, where if it updates a location, and does
not
    find what it expects to find, output a nasty bug.

< will skip patch 4 >

5 - Does what you want, with the 2 and 5 byte nops.

6 - When/if a failure does trigger. Print out information to what went
    wrong. Helps debugging splats caused by patch 3.

7 - needs to go before patch 3. As patch 3 can trigger if the default
nop
    is not the ideal nop for the box that is running. <reported by Ingo>


If I take out patch 4, would that solution look fine for you? I can get
this ready for 3.12.

-- Steve


--
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/