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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <481639D2.7040306@goop.org>
Date:	Mon, 28 Apr 2008 13:55:46 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	Jiri Slaby <jirislaby@...il.com>,
	David Miller <davem@...emloft.net>, zdenek.kabelac@...il.com,
	rjw@...k.pl, paulmck@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
	linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
	penberg@...helsinki.fi, clameter@....com,
	linux-kernel@...r.kernel.org, pageexec@...email.hu
Subject: Re: [PATCH 1/1] x86: fix text_poke

Ingo Molnar wrote:
> And once we accept the static 
> markers, we might as well make them as cheap as possible.

Sure, so long as you take "as cheap as possible" to mean cheap in both 
implementation complexity as well as runtime cost.

I don't have any specific objections to any of the stuff that Mathieu is 
working on, but it does worry me that each time a problem is addressed 
it ends up being an even more subtle piece of code.  I just haven't seen 
enough concrete justification to make me feel comfortable with it all.

It seems to me that a relatively simple implementation which allows the 
desired tracing/marking functionality is the first step.  If that proves 
to cause a significant performance deficit then enabled then we can work 
out how to address it in due course.  But doing it all at once before 
merging anything seems like overkill, particularly when we're talking 
about specifics of gcc's codegen patterns, disassembling code fragments, 
etc.

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