On 05/18, Mike Christie wrote:
>
> On 5/18/23 11:25 AM, Oleg Nesterov wrote:
> > I too do not understand the 1st change in this patch ...
> >
> > On 05/18, Mike Christie wrote:
> >>
> >> In the other patches we do:
> >>
> >> if (get_signal(ksig))
> >> start_exit_cleanup_by_stopping_newIO()
> >> flush running IO()
> >> exit()
> >>
> >> But to do the flush running IO() part of this I need to wait for it so
> >> that's why I wanted to be able to dequeue the SIGKILL and clear the
> >> TIF_SIGPENDING bit.
> >
> > But get_signal() will do what you need, dequeue SIGKILL and clear SIGPENDING ?
> >
> > if ((signal->flags & SIGNAL_GROUP_EXIT) ||
> > signal->group_exec_task) {
> > clear_siginfo(&ksig->info);
> > ksig->info.si_signo = signr = SIGKILL;
> > sigdelset(¤t->pending.signal, SIGKILL);
> >
> > this "dequeues" SIGKILL,
OOPS. this doesn't remove SIGKILL from current->signal->shared_pending
> >
> > trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
> > &sighand->action[SIGKILL - 1]);
> > recalc_sigpending();
> >
> > this clears TIF_SIGPENDING.
No, I was wrong, recalc_sigpending() won't clear TIF_SIGPENDING if
SIGKILL is in signal->shared_pending
> I see what you guys meant. TIF_SIGPENDING isn't getting cleared.
> I'll dig into why.
See above, sorry for confusion.
And again, there is another problem with SIGSTOP. To simplify, suppose
a PF_IO_WORKER thread does something like
while (signal_pending(current))
get_signal(...);
this will loop forever if (SIGNAL_GROUP_EXIT || group_exec_task) and
SIGSTOP is pending.
Oleg.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
