linux-kernel - Re: [patch 1/8] Immediate Values - Global Modules List and Module Mutex

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: <1189487938.20631.53.camel@localhost.localdomain>
Date:	Tue, 11 Sep 2007 15:18:58 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Alexey Dobriyan <adobriyan@...il.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch 1/8] Immediate Values - Global Modules List and Module
	Mutex

On Mon, 2007-09-10 at 20:45 -0400, Mathieu Desnoyers wrote:
> Code patching of _live_ SMP code is allowed. This is why I went through
> all this trouble on i386.

Oh, I was pretty sure it wasn't.  OK.

So now why three versions of immediate_set()?  And why are you using my
lock for exclusion?  Against what?

Why not just have one immediate_set() which iterates through and fixes
up all the references?  It can use an internal lock if you want to avoid
concurrent immediate_set() calls.

I understand the need for a "module_immediate_fixup()" but that can also
use your internal lock.

> > 2) immediate_if() needs an implementation before you introduce it.  Your
> > assumption that it's always unlikely seems non-orthogonal.
> 
> I could remove the unlikely(), no problem with that. Your point about
> this is valid. However, I would like to leave the immediate_if() there
> because it may become very useful if someday gcc permits to extract the
> address of a branch instruction (and to generate assembly that would not
> be reached without doing code patching).

Why is it easier to patch the sites now than later?  Currently it's just
churn.  You could go back and find them when this mythical patch gets
merged into this mythical future gcc version.  It could well need a
completely different macro style, like "cond_imm(var, code)".

Rusty.

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