On Thu, Jan 13, 2022 at 1:37 PM Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Sun, 9 Jan 2022 at 16:51, Warner Losh <i...@bsdimp.com> wrote: > > > > Fill in queue signal implementation, as well as routines allocate and > > delete elements of the signal queue. > > See reply to patch 18 for why you probably don't want to do this. > I've kept the former bits (implementing queue_signal() function), but removed the rest. > > Signed-off-by: Stacey Son <s...@freebsd.org> > > Signed-off-by: Kyle Evans <kev...@freebsd.org> > > Signed-off-by: Warner Losh <i...@bsdimp.com> > > --- > > > > + /* > > + * FreeBSD signals are always queued. Linux only queues real time > signals. > > + * XXX this code is not thread safe. "What lock protects > ts->sigtab?" > > + */ > > ts->sigtab shouldn't need a lock, because it is per-thread, > like all of TaskState. (The TaskState structure is pointed > to by the CPUState 'opaque' field. CPUStates are per-thread; > the TaskState for a new thread's new CPUState is allocated > and initialized as part of the emulating of whatever the > "create new thread" syscall is. For Linux this is in > do_fork() for the CLONE_VM case. The TaskState for the > initial thread is allocated in main.c.) We do need to deal > with the fact that ts->sigtab can be updated by a signal > handler (which always runs in the thread corresponding to > that guest CPU): the linux-user process_pending_signals() > has been written with that in mind. > Gotcha. That makes sense. Any reason that atomics aren't used for this between the different routines? Warner
