From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
prasad@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, Christoph Hellwig <hch@infradead.org>,
"Frank Ch. Eigler" <fche@redhat.com>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: text_poke, vmap and vmalloc on x86_64
Date: Wed, 16 Apr 2008 17:22:41 -0400 [thread overview]
Message-ID: <20080416212241.GA2621@Krystal> (raw)
In-Reply-To: <20080416201045.GA31199@Krystal>
* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> Hi,
>
> I am trying to figure out why the following code seems to work fine on
> x86_32, but the update fails to happen on x86_64. Any idea why ? From
> what I see the memcpy seems to fall in a memory area which is not the
> same as the one I test at the end of the function. It only fails for
> module addresses, which are vmalloc'd. Once I fix this, I'll be able to
> send the patchset.
>
Ah, found it. the is_vmalloc_addr() is somewhat misleading because it
does not include the vmalloc'd memory for modules, which is in a
different address space. I wonder if it has other unknown side-effects.
I used !core_kernel_text() instead.
Mathieu
> (from my own alternative.c) :
>
> void *__kprobes text_poke(void *addr, const void *opcode, size_t len)
> {
> unsigned long flags;
> char *vaddr;
> int nr_pages = 2;
> struct page *pages[2];
> int i;
>
> if (*((uint8_t *)addr - 1) != BREAKPOINT_INSTRUCTION) {
> BUG_ON(len > sizeof(long));
> BUG_ON((((long)addr + len - 1) & ~(sizeof(long) - 1))
> - ((long)addr & ~(sizeof(long) - 1)));
> }
> if (is_vmalloc_addr(addr)) {
> pages[0] = vmalloc_to_page(addr);
> pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
> } else {
> pages[0] = virt_to_page(addr);
> pages[1] = virt_to_page(addr + PAGE_SIZE);
> }
> BUG_ON(!pages[0]);
> if (!pages[1])
> nr_pages = 1;
> vaddr = vmap(pages, nr_pages, VM_MAP, PAGE_KERNEL);
> BUG_ON(!vaddr);
> local_irq_save(flags);
> memcpy(&vaddr[(unsigned long)addr & ~PAGE_MASK], opcode, len);
> local_irq_restore(flags);
> vunmap(vaddr);
> sync_core();
> /* Could also do a CLFLUSH here to speed up CPU recovery; but
> that causes hangs on some VIA CPUs. */
> for (i = 0; i < len; i++)
> BUG_ON(((char *)addr)[i] != ((char *)opcode)[i]);
> return addr;
> }
>
> Mathieu
>
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-04-16 21:27 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-15 11:50 [RFC PATCH 0/2] Debugging infrastructure for Futexes using Markers K. Prasad
2008-04-15 11:53 ` [RFC PATCH 1/2] Marker probes in futex.c K. Prasad
2008-04-15 11:55 ` [RFC PATCH 2/2] Marker handler for the probes in futex file K. Prasad
2008-04-15 12:02 ` [RFC PATCH 1/2] Marker probes in futex.c Peter Zijlstra
2008-04-15 12:32 ` Mathieu Desnoyers
2008-04-15 12:50 ` Alexey Dobriyan
2008-04-15 16:13 ` K. Prasad
2008-04-15 12:56 ` Peter Zijlstra
2008-04-15 13:17 ` Ingo Molnar
2008-04-15 13:47 ` Mathieu Desnoyers
2008-04-15 14:04 ` Ingo Molnar
2008-04-15 14:21 ` Frank Ch. Eigler
2008-04-15 14:39 ` Mathieu Desnoyers
2008-04-15 16:48 ` Ingo Molnar
2008-04-15 21:38 ` Mathieu Desnoyers
2008-04-16 13:17 ` Ingo Molnar
2008-04-16 13:46 ` Arjan van de Ven
2008-04-16 14:00 ` Mathieu Desnoyers
2008-04-16 14:24 ` Arjan van de Ven
2008-04-16 14:29 ` Ingo Molnar
2008-04-16 14:48 ` Mathieu Desnoyers
2008-04-16 15:32 ` Arjan van de Ven
2008-04-16 15:39 ` Mathieu Desnoyers
2008-04-16 20:10 ` text_poke, vmap and vmalloc on x86_64 Mathieu Desnoyers
2008-04-16 21:22 ` Mathieu Desnoyers [this message]
2008-04-15 13:25 ` [RFC PATCH 1/2] Marker probes in futex.c Mathieu Desnoyers
2008-04-16 15:51 ` Peter Zijlstra
2008-04-17 19:19 ` Frank Ch. Eigler
2008-04-17 20:16 ` Mathieu Desnoyers
2008-04-19 12:13 ` K. Prasad
2008-04-19 21:33 ` Mathieu Desnoyers
2008-04-18 6:56 ` Peter Zijlstra
2008-04-15 15:52 ` K. Prasad
2008-04-16 15:51 ` Peter Zijlstra
2008-04-17 22:02 ` Frank Ch. Eigler
2008-04-18 6:46 ` Peter Zijlstra
2008-04-18 14:29 ` Frank Ch. Eigler
2008-04-19 12:28 ` K. Prasad
2008-04-19 14:52 ` Peter Zijlstra
2008-04-19 18:03 ` Frank Ch. Eigler
2008-04-19 18:29 ` Peter Zijlstra
2008-04-19 18:48 ` Frank Ch. Eigler
2008-04-22 17:50 ` Nicholas Miell
2008-04-19 14:13 ` Mathieu Desnoyers
2008-04-19 14:56 ` Peter Zijlstra
2008-04-18 10:44 ` Andrew Morton
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=20080416212241.GA2621@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=a.p.zijlstra@chello.nl \
--cc=arjan@infradead.org \
--cc=fche@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=prasad@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.