Re: [RFC PATCH] gdbstub: handle a potentially racing TaskState

[Richard Henderson <richard.henderson@linaro.org>]

On 11/19/21 3:51 PM, Alex Bennée wrote:
> When dealing with multi-threaded userspace programs there is a race
> condition with the addition of cpu->opaque (aka TaskState). This is
> due to cpu_copy calling cpu_create which updates the global vCPU list.
> However the task state isn't set until later. This shouldn't be a
> problem because the new thread can't have executed anything yet but
> the gdbstub code does liberally iterate through the CPU list in
> various places.
> 
> This sticking plaster ensure the not yet fully realized vCPU is given
> an pid of -1 which should be enough to ensure it doesn't show up
> anywhere else.
> 
> In the longer term I think the code that manages the association
> between vCPUs and attached GDB processes could do with a clean-up and
> re-factor.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/730
> ---
>   gdbstub.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdbstub.c b/gdbstub.c
> index 23baaef40e..141d7bc4ec 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -94,7 +94,7 @@ static inline int cpu_gdb_index(CPUState *cpu)
>   {
>   #if defined(CONFIG_USER_ONLY)
>       TaskState *ts = (TaskState *) cpu->opaque;
> -    return ts->ts_tid;
> +    return ts ? ts->ts_tid : -1;
>   #else
>       return cpu->cpu_index + 1;
>   #endif

Tested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~