Re: [RFC] Set process affinity in test to work around ARM ptrace bug

[Yao Qi <qiyaoltc at gmail dot com>]

Ping.

On Mon, Jul 4, 2016 at 11:49 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
> Pedro Alves <palves@redhat.com> writes:
>
>> I also think that whatever workaround, if any, should be limited
>> to known-broken kernels.  Otherwise, this is likely to mask
>> other problems going forward.  Maybe all we have is the version
>> number to work with, but that's still better than unconditionally
>> enabling this on arm.
>
> The updated version adds a linux kernel version check.
>
> --
> Yao (齐尧)
> From 27fe094e6a99929f8f281d88beaa599771550025 Mon Sep 17 00:00:00 2001
> From: Yao Qi <yao.qi@linaro.org>
> Date: Mon, 27 Jun 2016 08:45:16 +0100
> Subject: [PATCH] Set process affinity in test to work around ARM ptrace bug
>
> We recently found a ARM kernel ptrace bug
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/431962.html
> As a result of this bug, after GDB ptrace set VFP registers, the hardware
> registers may not be updated.  This bug causes some intermittent fails in
> tests, like return.exp, call-rt-st.exp, callfuncs.exp, etc.
>
> The bug was introduced by 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f
> in 2012 and is fixed in e2dfb4b880146bfd4b6aa8e138c0205407cebbaf in May.
> The bug is fixed in ARM kernel tree, but it is impractical to upgrade
> linux kernel from git tree or most recently release.  I am wondering
> we can workaround this kernel bug somehow.
>
> My first attempt is to workaround it in GDB, so that GDB still writes
> the VFP registers and sync them to hardware.  The kernel patch is quite
> simple, which moves vfp_flush_hwstate one line below.  Probably, we can
> call ptrace set vfp registers twice, and then the second vfp set can
> flush the state correctly.  Unfortunately, it doesn't work, because
> every time of ptrace set, kernel loads VFP registers from hardware first,
> which might be out of date after the first ptrace set.  That is to say,
> we can't workaround this kernel bug in GDB.
>
> Then, I am thinking we can workaround this bug in testing, because the
> intermittent fails are confusing in comparing test results.  We can bind
> both tracer and tracee on the same core.  For example, we can start GDB
> or GDBserver with "taskset -c 0 ", but this is a global change, may
> have some affects on gdb.threads tests.  I also think about doing
> "taskset -p PID -c 0" in test harness after the inferior is started,
> and do the same to the parent process of inferior (which is either GDB
> or GDBserver), but don't know how to get GDB (in remote host) and
> GDBserver's process id.
>
> The approach in this patch is to have a small c function which sets
> both process affinity and its parent's affinity to core 0 if the target
> is arm linux and the kernel version is known broken having the ptrace
> bug setting VFP registers.  The function set_process_affinity should
> be called in these tests explicitly, but other tests are not affected
> at all.
>
> Note that this kernel bug only exists between commits
> 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f and e2dfb4b880146bfd4b6aa8e138c0205407cebbaf
> However, a certain commit will be merged to many branches and releases,
> which makes version checks complicated.  I checked all released kernels,
> and get a list of versions that this bug is fixed.  Not all longterm
> kernels on kernel.org have this bug fix, I don't know why, for example,
> some 3.x kernels doesn't have this bug fix.
>
> Secondly, kernels older than 8130b9d7b9d858aa04ce67805e8951e3cb6e9b2f
> are not affected by this bug, so the official kernel releases older
> than 3.0.21 or 3.2.6 are not affected by this bug, but I think the
> distro may backport the commit to their older kernel, so it makes few
> sense to check kernel is older than some versions (3.0.21 and 3.2.6).
>
> gdb/testsuite:
>
> 2016-07-04  Yao Qi  <yao.qi@linaro.org>
>
>         * lib/set_process_affinity.c: New file.
>
>         * gdb.arch/arm-neon.c: Include lib/set_process_affinity.c.
>         (main): Call set_process_affinity.
>         * gdb.base/callfuncs.c: Likewise.
>         * gdb.base/call-rt-st.c: Likewise.
>         * gdb.base/gnu_vector.c: Likewise.
>         * gdb.base/return.c: Likewise.
>         * gdb.base/return2.c: Likewise.
>         * gdb.base/store.c: Likewise.
>         * gdb.base/structs.c: Likewise.
>         * gdb.arch/arm-neon.exp: Set breakpoint and continue to
>         breakpoint.
>         * gdb.base/gnu_vector.exp: Likewise.
>

-- 
Yao (齐尧)