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 05:10 PM, David Smith wrote:

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


(stuff from Will deleted that describes a problem on IA64/ARM where some
new code I added that calls our __access_process_vm() comes up with an
undefined symbol)

Here's some more background and context here.  The kernel has
_acesss_process_vm() but it isn't exported.  So, we have an internal
copy called __access_process_vm(). We also have a variant, called
__access_process_vm_noflush(), that doesn't flush the instruction cache.
 This variant isn't present upstream.

Our __access_process_vm() calls copy_from_user_page() and
copy_to_use_page() to do the actual reading/writing. There is a default
definition of those functions present in
include/asm-generic/cacheflush.h that looks like this:

====

....
#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)

#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
        memcpy(dst, src, len)
====

So, copy_to_user_page()/copy_from_user_page() boil down to just memcpy().

Here's how each arch we're interested in handles
copy_to_user_page()/copy_from_user_page() in the current upstream kernel
source.

- x86, x86_64: Just uses the default.
- s390x: Just uses the default.
- ia64: flush_icache_user_range() is a define that calls
flush_icache_range(), which isn't exported
- mips: has unexported copy_to_user_page()/copy_from_user_page() functions
- arm: copy_from_user_page() is just #defined to be memcpy().
copy_to_user_page() is an unexported function

So, we've got problems on ia64, mips, and arm.

Note that I'm a bit worried that __access_process_vm_noflush() isn't
quite right on mips, since it doesn't call its arch specific
copy_from_user_page() (all other arches just use memcpy to read).  But,
the mips arch-specific copy_from_user_page() isn't exported.  We'd
someone who understands mips details to look at the internals of
copy_from_user_page() to know if the differences are important.

So, that's the status of __access_process_vm() on all the arches that
systemtap runs on.

However...


I realized while looking at this (prompted by Will) that the build-id
checking code is only reading user memory, not writing it.  When reading
user memory, __access_process_vm() and __access_process_vm_noflush() are
fairly equivalent.  So, I've switch the build-id checking code to use
__access_process_vm_noflush() (commit f1410a8).

This should hopefully fix ia64, mips, and arm on current kernels.

Will, if this doesn't fix ARM, let me know.

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