| Message ID | 20211119145124.942390-1-alex.bennee@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [RFC] gdbstub: handle a potentially racing TaskState | expand |
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~
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
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(-)