Re: [PATCH 0/3] kprobes: add new dma insn slot cache for s390

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

Hi Heiko,

(2013/08/21 21:01), Heiko Carstens wrote:
> The current kpropes insn caches allocate memory areas for insn slots with
> module_alloc(). The assumption is that the kernel image and module area
> are both within the same +/- 2GB memory area.
> This however is not true for s390 where the kernel image resides within
> the first 2GB (DMA memory area), but the module area is far away in the
> vmalloc area, usually somewhere close below the 4TB area.
> 
> For new pc relative instructions s390 needs insn slots that are within
> +/- 2GB of each area. That way we can patch displacements of pc-relative
> instructions within the insn slots just like x86 and powerpc.
> 
> The module area works already with the normal insn slot allocator, however
> there is currently no way to get insn slots that are within the first 2GB
> on s390 (aka DMA area).

The reason why we allocate instruction buffers from module area is
to execute a piece of code on the buffer, which should be executable.
I'm not good for s390, is that allows kernel to execute the code
on such DMA buffer?

> Therefore this patch set introduces a third insn slot cache besides the
> normal insn and optinsn slot caches: the dmainsn slot cache. Slots can be
> allocated and freed with get_dmainsn_slot() and free_dmainsn_slot().

OK, but it seems that your patch introduced unneeded complexity. Perhaps,
you just have to introduce 2 weak functions to allocate/release such
executable and jump-able buffers, like below,

void * __weak arch_allocate_executable_page(void)
{
	return module_alloc(PAGE_SIZE);
}

void __weak arch_free_executable_page(void *page)
{
	module_free(NULL, page);
}

Thus, all you need to do is implementing dmaalloc() version of above
functions on s390. No kconfig, no ifdefs are needed. :)

> 
> Patch 1 unifies the current insn and optinsn caches implementation so we
> don't end up with a lot of code duplication when adding a third cache.
> 
> Patch 2 simply adds the new dmainsn slot cache.
> 
> Patch 3 is the s390 usage of the new cache.
> 
> Looking at the last couple of sign-off chains I'm not sure how kprobes
> patches should go upstream.. Andrew, Ingo, or simply via the s390 tree?

Hmm, AFAIK, currently all noarch kprobes works go to -tip tree, and
the arch dependent parts go to each arch tree (only x86 goes to -tip tree).

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com