Re: Improve build-id checking when the task we're interested in isn't 'current'. git commit causing problems on ARM and IA64

[David Smith <dsmith at redhat dot com>]

On 04/02/2012 03:16 PM, William Cohen wrote:

> On 04/02/2012 03:30 PM, David Smith wrote:
>> ../install/bin/stap  -k ../systemtap/testsuite/systemtap.base/add.stp 
> 
> Hi David,
> 
> Thanks for taking a look at this problem.
> 
> The git checkin fixes the problem for ia64.
> 
> The arm machine is using a kernel from the linus torvald's git repo. This particular kernel doesn't

> have utrace support in it, so it doesn't have CONFIG_UTRACE set.
> Thus, things still fail in the same way on the ARM machine.

> 
> Does this code work with stock x86_64 kernel?  I am wondering why this problem wasn't seen on the x86

> machine. Does the x86 not need to do the explicit flushes unlike the
> ia64 and ARM?

Right.  From what I've been looking at on the stock x86_64 kernel,
copy_to_user_page() boils down to a memcpy() call.

Since x86_64 doesn't have an arch-specific cacheflush.h file, it
inherits the following from asm-generic/cacheflush.h:

====
....
#define flush_icache_user_range(vma,pg,adr,len) do { } while (0)
....
#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
        do { \
                memcpy(dst, src, len); \
                flush_icache_user_range(vma, page, vaddr, len); \
        } while (0)
====

Arm has a arch-specific copy_to_user_page() (defined in
arch/arm/include/cacheflush.h) which isn't exported.  Sigh.

It looks like on current kernels access_process_vm() is exported, which
means we could use the real function instead of our copy (can you check
and make sure this is exported on arm?).  However, we've added the
__access_process_vm_noflush() variant which isn't present upstream.

I'm not sure there are easy answers here.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)