bugfix for strace for less-aligned kernel memory

[Bolo]

> > This bugfix / patch consists of two portions
> >=20
> > 1) A 'Z' option which forces strace to use ptrace() memory access
> > routines all the time instead of vm-based memory access routines if
> > they are present..  This allows a fallback if you find that VM based
> > requests are failing or producing incorrect output.   The existing
> > ptrace based methods are quite robust and tested :-)
> 
> As there are no known issues with kernel implementation of process_vm_readv,
> why should anybody want to disable fast process_vm_readv based code
> in favour of slow PTRACE_PEEKDATA based one?

The kernel implementation is correct; however there are issues
with strace's use of that feature; hence the bugfix.

The option allows one to disable the process_vm_readv at the user's
choice, so that they can see if the problem exists with both methods
of ptrace memory access, or only happens with with vm_process_readv().

It also allows testing of strace with the same kernel interface on
multiple variants of linux, and give performance comparisons.  It 
also allows comparing linux ptrace/vm_process_readv to ptrace on
other platforms.


> Well, it was a genuine bug in process_vm_readv based code, thank you for
> reporting it, although I haven't got it from your description and patch
> after the first read.
> 
> It's fixed by commit v4.10-56-g4832134 which also contains a regression
> test.  There is also a follow-up cleanup commit v4.10-57-gea1fea6.

Thanks.

I noticed afte the fact I hadn't moved the fixes to the comments forward
from the strace-5.8 fix due to random changes in that comment in the middle.

> I've tried to reproduce alignment issues with process_vm_readv from your
> description, but without success.

It is difficult to reproduce, but it is reproducible.   Our project,
the SWAMP, happens to run millions of strace invocations, and the
sample set size is large enough that this bug surfaces about 1%
of the time.    Sometimes it can be 100% with the compilation of a
package on some linux platforms.  Reproducibility can depend on the
exact amount of memory in the machine, and other factors, such as
process scheduling or other things happening on a system which are
beyond control.


> > When this alignment constraint is relaxed, or strace incorrectly issues
> > reads across page boundaries, strace fails with a error of
> >=20
> > 	"umovestr: short read (%d < %d) @0x%lx"
> >=20
> > due to the incorect code.  In addition, since the vm-based code doesn't
> > correctly update the address and lengths of the region to be accessed,
> > the fallback code -- which is implemented correctly, fails to work.
> 
> There is no fallback to PTRACE_PEEKDATA based code in case when
> process_vm_readv has read at least one byte.

It has been about a year since I worked on this, and I put it into
the current strace last month.   I believe that the fixes I provide do
allow fallback to work correctly in the face of process_vm_readv()
failure.   I may have left out some of the code which allowed it;
it has been a while since it has been on my mind.

I would need to go back and review last years test cases to
verify that, however.


> > The new code also deals with arbitrary page sizes correctly in extracting
> > data using the vm mode, instead of relying upon a 4k pagesize.
> >=20
> > 3) Reproducing this error depends upon where the kernel is putting items
> > in memory, and may also be based on the load of the kernel.   As such,
> > this error can be difficult to reproduce.
> 
> Actually, the reproducer is quite simple:
> http://sourceforge.net/p/strace/code/ci/HEAD/tree/tests/umovestr.c

Nice.


Bolo -- Josef T. Burger