linux-kernel - Re: [PATCH 2/5] ftrace: use code patching for ftrace graph tracer

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:	Wed, 26 Nov 2008 00:44:48 -0800
From:	Harvey Harrison <harvey.harrison@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	containers@...ts.osdl.org,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 2/5] ftrace: use code patching for ftrace graph tracer

On Wed, 2008-11-26 at 00:35 -0800, Andrew Morton wrote:
> On Wed, 26 Nov 2008 00:27:04 -0800 Harvey Harrison <harvey.harrison@...il.com> wrote:
> 
> > if (code[0] != 0xe9 || old_offset != load32_noalign(&code[1]))
> > 
> > This is similar to the new API in -mm load_le32_noalign, but I
> > don't think it would be worth load_u32_noalign...load32 should
> > be enough.
> > 
> > > > > > +		return -EINVAL;
> > > > > > +
> > > > > > +	*(int *)(&code[1]) = new_offset;
> > > > > 
> > > > > Might be able to use put_unaligned_foo() here.
> > > > > 
> > > > 
> > > > 	put_unaligned(new_offset, (int *)(&code[1]));
> > > > 
> > 
> > In a similar vein to above, this becomes:
> > 
> > 	store32_noalign(&code[1], new_offset);
> > 
> 
> yes, that's much better than the party tricks with magical sizeof,
> which forces you to run around and check the types of everything.
> 
> I've seen people doing get_user() on `long' types and such things
> occasionally.
> 

Do you want to carry the patches to move to the new helpers until they
hit mainline, or would you rather I waited until they can go through
maintainer trees?

I've got the pile ready removing all of the get/put_{endian} and moving
to the load/store API.  Not much left after that to just remove the
magical sizeof versions too.  Just let me know what timing you'd prefer.

Also, all of this ends up being so intertwined in the aligned/unaligned
cases that I'd like to move most of Documentation/unaligned_memory_access.txt
into a new alignment_and_byteorder.txt to cover all of these new helpers.

I started most of a byteorder document, but constantly referring to the other
file made it a bit tiresome, would you mind a consolidated document?

Harvey

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