Messages in this thread | | | Subject | Re: For review: seccomp_user_notif(2) manual page | From | "Michael Kerrisk (man-pages)" <> | Date | Tue, 27 Oct 2020 07:14:03 +0100 |
| |
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@gmail.com> 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/
| |