On 10/26/20 4:54 PM, Jann Horn wrote: > On Sun, Oct 25, 2020 at 5:32 PM Michael Kerrisk (man-pages) > <mtk.manpages@xxxxxxxxx> wrote: [...] >> I tried applying the patch below to vanilla 5.9.0. >> (There's one typo: s/ENOTCON/ENOTCONN). >> >> It seems not to work though; when I send a signal to my test >> target process that is sleeping waiting for the notification >> response, the process enters the uninterruptible D state. >> Any thoughts? > > Ah, yeah, I think I was completely misusing the wait API. I'll go change that. > > (Btw, in general, for reports about hangs like that, it can be helpful > to have the contents of /proc/$pid/stack. And for cases where CPUs are > spinning, the relevant part from the output of the "L" sysrq, or > something like that.) Thanks for the tipcs! > Also, I guess we can probably break this part of UAPI after all, since > the only user of this interface seems to currently be completely > broken in this case anyway? So I think we want the other > implementation without the ->canceled_reqs logic after all. Okay. > I'm a bit on the fence now on whether non-blocking mode should use > ENOTCONN or not... I guess if we returned ENOENT even when there are > no more listeners, you'd have to disambiguate through the poll() > revents, which would be kinda ugly? I must confess, I'm not quite clear on which two cases you are trying to distinguish. Can you elaborate? > I'll try to turn this into a proper patch submission... Thank you!! Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
