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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1189725317.7262.23.camel@localhost.localdomain>
Date:	Fri, 14 Sep 2007 09:15:17 +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 Thu, 2007-09-13 at 17:21 -0400, Mathieu Desnoyers wrote:
> * Rusty Russell (rusty@...tcorp.com.au) wrote:
> > Sure, but why is that the caller's problem?  immediate_set() isn't
> > fastpath, so why not make it do an "if (early_boot)" internally?
> 
> I see two reasons:
> 1 - early_boot, or anything that looks like this, does not exist
> currently (and the following reason might show why).
> 2 - If we use this, we cannot declare the early code with __init, so it
> will have to stay there forever insteaf of being removable once boot is
> over.
> 
> Therefore, I think it's better to stick to an immediate_set_early
> version.

My problem is that I don't know when to use immediate_set_early!  You
say "early boot": what does that mean?  Is it arch-specific?  And why is
it my problem anyway?

Since arch_immediate_update_early() is a memcpy, I don't really buy the
bloat argument (it has some silly-looking optimization, but that should
be removed anyway).  I'd really rather see arch_immediate_update()
examine an internal flag and do the memcpy if it's too early for the
full algorithm.  That's the only place which really knows, after all.
You may need some external hook to update that internal "too early"
flag, of course.

Alternatively, if you called it "immediate_init" then the semantics
change slightly, but are more obvious (ie. only use this when the value
isn't being accessed yet).  But it can't be __init then anyway.

On an unrelated note, did you consider simply IPI-ing and doing the
substitution with all CPUs stopped?  If you only updated the immediate
references to this particular var, it should be fast enough not to upset
the RT guys, even.

> > I was thinking that we might find useful specific cases before we get
> > GCC support, which archs can override with tricky asm if they wish.
> > 
> 
> The first useful case is the Linux Kernel Markers, which really needs a
> completely boolean if: active or inactive. That would be a good test
> case to get gcc support.

Well, you can do that in asm without gcc support.  It's a little nasty:
since gcc will know nothing about the function call, it can't have side
effects which are visible in this function, and you'll have to save and
restore *all* regs if you decide to do the function call.  But it's
possible (a 5-byte nop gets changed to a call, the call does the pushes
and sets the args regs, calls the function, then pops everything and
rets).

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