| Message ID | 20210420081614.684787-1-pbonzini@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: selftests: Always run vCPU thread with blocked SIG_IPI | expand |
On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: > The main thread could start to send SIG_IPI at any time, even before signal > blocked on vcpu thread. Therefore, start the vcpu thread with the signal > blocked. > > Without this patch, on very busy cores the dirty_log_test could fail directly > on receiving a SIGUSR1 without a handler (when vcpu runs far slower than main). > > Reported-by: Peter Xu <peterx@redhat.com> > Cc: stable@vger.kernel.org > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Yes, indeed better! :) Reviewed-by: Peter Xu <peterx@redhat.com>
On Tue, Apr 20, 2021 at 10:37:39AM -0400, Peter Xu wrote: > On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: > > The main thread could start to send SIG_IPI at any time, even before signal > > blocked on vcpu thread. Therefore, start the vcpu thread with the signal > > blocked. > > > > Without this patch, on very busy cores the dirty_log_test could fail directly > > on receiving a SIGUSR1 without a handler (when vcpu runs far slower than main). > > > > Reported-by: Peter Xu <peterx@redhat.com> > > Cc: stable@vger.kernel.org > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > > Yes, indeed better! :) > > Reviewed-by: Peter Xu <peterx@redhat.com> I just remembered one thing: this will avoid program quits, but still we'll get the signal missing. From that pov I slightly prefer the old patch. However not a big deal so far as only dirty ring uses SIG_IPI, so there's always ring full which will just delay the kick. It's just we need to remember this when we extend IPI to non-dirty-ring tests as the kick is prone to be lost then. Thanks,
On 20/04/21 17:32, Peter Xu wrote: > On Tue, Apr 20, 2021 at 10:37:39AM -0400, Peter Xu wrote: >> On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: >>> The main thread could start to send SIG_IPI at any time, even before signal >>> blocked on vcpu thread. Therefore, start the vcpu thread with the signal >>> blocked. >>> >>> Without this patch, on very busy cores the dirty_log_test could fail directly >>> on receiving a SIGUSR1 without a handler (when vcpu runs far slower than main). >>> >>> Reported-by: Peter Xu <peterx@redhat.com> >>> Cc: stable@vger.kernel.org >>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >> >> Yes, indeed better! :) >> >> Reviewed-by: Peter Xu <peterx@redhat.com> > > I just remembered one thing: this will avoid program quits, but still we'll get > the signal missing. In what sense the signal will be missing? As long as the thread exists, the signal will be accepted (but not delivered because it is blocked); it will then be delivered on the first KVM_RUN. Paolo From that pov I slightly prefer the old patch. However > not a big deal so far as only dirty ring uses SIG_IPI, so there's always ring > full which will just delay the kick. It's just we need to remember this when we > extend IPI to non-dirty-ring tests as the kick is prone to be lost then. > > Thanks, >
On Tue, Apr 20, 2021 at 06:24:50PM +0200, Paolo Bonzini wrote: > On 20/04/21 17:32, Peter Xu wrote: > > On Tue, Apr 20, 2021 at 10:37:39AM -0400, Peter Xu wrote: > > > On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote: > > > > The main thread could start to send SIG_IPI at any time, even before signal > > > > blocked on vcpu thread. Therefore, start the vcpu thread with the signal > > > > blocked. > > > > > > > > Without this patch, on very busy cores the dirty_log_test could fail directly > > > > on receiving a SIGUSR1 without a handler (when vcpu runs far slower than main). > > > > > > > > Reported-by: Peter Xu <peterx@redhat.com> > > > > Cc: stable@vger.kernel.org > > > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > > > > > > Yes, indeed better! :) > > > > > > Reviewed-by: Peter Xu <peterx@redhat.com> > > > > I just remembered one thing: this will avoid program quits, but still we'll get > > the signal missing. > > In what sense the signal will be missing? As long as the thread exists, the > signal will be accepted (but not delivered because it is blocked); it will > then be delivered on the first KVM_RUN. Ah right.. Thanks,
diff --git a/tools/testing/selftests/kvm/dirty_log_test.c b/tools/testing/selftests/kvm/dirty_log_test.c index ffa4e2791926..81edbd23d371 100644 --- a/tools/testing/selftests/kvm/dirty_log_test.c +++ b/tools/testing/selftests/kvm/dirty_log_test.c @@ -527,9 +527,8 @@ static void *vcpu_worker(void *data) */ sigmask->len = 8; pthread_sigmask(0, NULL, sigset); + sigdelset(sigset, SIG_IPI); vcpu_ioctl(vm, VCPU_ID, KVM_SET_SIGNAL_MASK, sigmask); - sigaddset(sigset, SIG_IPI); - pthread_sigmask(SIG_BLOCK, sigset, NULL); sigemptyset(sigset); sigaddset(sigset, SIG_IPI); @@ -858,6 +857,7 @@ int main(int argc, char *argv[]) .interval = TEST_HOST_LOOP_INTERVAL, }; int opt, i; + sigset_t sigset; sem_init(&sem_vcpu_stop, 0, 0); sem_init(&sem_vcpu_cont, 0, 0); @@ -916,6 +916,11 @@ int main(int argc, char *argv[]) srandom(time(0)); + /* Ensure that vCPU threads start with SIG_IPI blocked. */ + sigemptyset(&sigset); + sigaddset(&sigset, SIG_IPI); + pthread_sigmask(SIG_BLOCK, &sigset, NULL); + if (host_log_mode_option == LOG_MODE_ALL) { /* Run each log mode */ for (i = 0; i < LOG_MODE_NUM; i++) {
The main thread could start to send SIG_IPI at any time, even before signal blocked on vcpu thread. Therefore, start the vcpu thread with the signal blocked. Without this patch, on very busy cores the dirty_log_test could fail directly on receiving a SIGUSR1 without a handler (when vcpu runs far slower than main). Reported-by: Peter Xu <peterx@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- tools/testing/selftests/kvm/dirty_log_test.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)