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>]

OK, obviously I needed more caffeine yesterday, because...

On 04/04/2012 03:56 PM, David Smith wrote:

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


Systemtap has never run on mips.  I don't know how ppc got confused with
mips in my head.

Here's how ppc handles copy_to_user_page()/copy_from_user_page():
flush_icache_user_range() is an exported function

The good news here is that memcpy() can be used just fine (in
__access_process_vm_noflush()) to read user memory on all the (real)
arches we care about.

Now I'm off to drink a diet coke...

-- 

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