From: Andi Kleen <andi@firstfloor.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Andi Kleen <andi@firstfloor.org>,
pageexec@freemail.hu
Subject: Re: [patch 05/10] Text Edit Lock - Alternative code for i386 and x86_64
Date: Fri, 7 Sep 2007 08:59:36 +0200 [thread overview]
Message-ID: <20070907065936.GH31880@one.firstfloor.org> (raw)
In-Reply-To: <20070906200212.080849869@polymtl.ca>
On Thu, Sep 06, 2007 at 04:01:29PM -0400, Mathieu Desnoyers wrote:
> + sync_core();
> + /* Not strictly needed, but can speed CPU recovery up. */
That turned out to break on some VIA CPUs. Should be removed.
> + if (cpu_has_clflush)
> + for (faddr = addr; faddr < addr + len;
> + faddr += boot_cpu_data.x86_clflush_size)
> + asm("clflush (%0) " :: "r" (faddr) : "memory");
> +}
> +
> +void * text_poke_early(void *addr, const void *opcode,
> + size_t len)
> +{
> + memcpy(addr, opcode, len);
It would be best to copy __inline_memcpy from x86-64 to i386
and use that here. That avoids the dependency on a patched
memcpy and is slightly safer.
> +
> + if (len > sizeof(long)) {
> + printk(KERN_ERR "text_poke of len %zu too big (max %lu)\n",
> + len, sizeof(long));
> + BUG_ON(1);
In general BUG_ON only should be enough because these values can
be recovered from the registers.
> + }
> + unaligned = (((long)addr + len - 1) & ~(sizeof(long) - 1))
> + - ((long)addr & ~(sizeof(long) - 1));
> + if (unlikely(unaligned)) {
> + printk(KERN_ERR "text_poke of at addr %p of len %zu is "
> + "unaligned (%d)\n",
> + addr, len, unaligned);
> + BUG_ON(1);
> + }
The common code should be in a common function. In fact they're so
similar that the caller could just pass a buffer for the text_set
case, couldn't it?
> +#define kernel_wp_save(cr0) \
Is there a real reason this has to be an macro? It could
be just a normal function. In fact a shared on in alternative.c.
That would also avoid adding more include dependencies.
> + do { \
> + typecheck(unsigned long, cr0); \
typecheck is probably overkill
> + preempt_disable(); \
Should disable interrupts too just to be safer?
-Andi
next prev parent reply other threads:[~2007-09-07 6:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-06 20:01 [patch 00/10] Text Edit Lock for 2.6.23-rc4-mm1 Mathieu Desnoyers
2007-09-06 20:01 ` [patch 01/10] Kprobes - use a mutex to protect the instruction pages list Mathieu Desnoyers
2007-09-06 20:01 ` [patch 02/10] Kprobes - do not use kprobes mutex in arch code Mathieu Desnoyers
2007-09-06 20:01 ` [patch 03/10] Kprobes - declare kprobe_mutex static Mathieu Desnoyers
2007-09-06 20:01 ` [patch 04/10] Text Edit Lock - Architecture Independent Code Mathieu Desnoyers
2007-09-06 20:01 ` [patch 05/10] Text Edit Lock - Alternative code for i386 and x86_64 Mathieu Desnoyers
2007-09-07 6:59 ` Andi Kleen [this message]
2007-09-07 14:04 ` Mathieu Desnoyers
2007-09-07 22:35 ` Andi Kleen
2007-09-11 19:59 ` Mathieu Desnoyers
2007-09-07 8:43 ` Ananth N Mavinakayanahalli
2007-09-07 14:09 ` Mathieu Desnoyers
2007-09-06 20:01 ` [patch 06/10] Text Edit Lock - kprobes architecture independent support Mathieu Desnoyers
2007-09-07 10:28 ` Ananth N Mavinakayanahalli
2007-09-07 14:13 ` Mathieu Desnoyers
2007-09-06 20:01 ` [patch 07/10] Text Edit Lock - kprobes i386 Mathieu Desnoyers
2007-09-06 20:01 ` [patch 08/10] Text Edit Lock - kprobes x86_64 Mathieu Desnoyers
2007-09-06 20:01 ` [patch 09/10] Text Edit Lock - i386 standardize debug rodata Mathieu Desnoyers
2007-09-06 20:01 ` [patch 10/10] Text Edit Lock - x86_64 " Mathieu Desnoyers
-- strict thread matches above, loose matches on Subject: below --
2007-08-27 15:56 [patch 00/10] Text Edit Lock Mathieu Desnoyers
2007-08-27 15:56 ` [patch 05/10] Text Edit Lock - Alternative code for i386 and x86_64 Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070907065936.GH31880@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=pageexec@freemail.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox