linux-kernel - Re: [PATCH] paravirt.h

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: <1156298131.12015.42.camel@localhost.localdomain>
Date:	Wed, 23 Aug 2006 11:55:31 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Zachary Amsden <zach@...are.com>
Cc:	Andi Kleen <ak@...e.de>, Andrew Morton <akpm@...l.org>,
	virtualization@...ts.osdl.org, Chris Wright <chrisw@...s-sol.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] paravirt.h

On Tue, 2006-08-22 at 15:02 -0700, Zachary Amsden wrote:
> Well, I don't think anything is sufficient for a preemptible kernel.  I 
> think that's just plain not going to work.  You could have a kernel 
> thread that got preempted in a paravirt-op patch point

Patching over the 6 native cases is actually not that bad: they're
listed below (each one has trailing noops).

	cli
	sti
	push %eax; popf
	pushf; pop %eax
	pushf; pop %eax; cli
	iret
	sti; sysexit

If you're at the first insn you don't have to do anything, since you're
about to replace that code.  If you're in the noops, you can just
advance EIP to the end.  You can't be preempted between sti and sysexit,
since we only use that when interrupts are already disabled.  And
reversing either "push %eax" or "pushf; pop %eax" is fairly easy.

Depending on your hypervisor, you might need to catch those threads who
are currently doing the paravirt_ops function calls, as well.  This
introduces more (and more complex) cases.

That all said, I've long speculated about a stop_machine which schedules
all the preempted threads, to ensure every thread is in a happy
unpreempt place.  This would involve scheduler hacks, but would allow us
to remove the preempt_disable() calls around try_module_get() and any
other areas which use stop_machine as the write side of locking.

Rusty.
-- 
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law

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