linux-kernel - Re: Sleeping thread not receive signal until it wakes up

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070310112203.33c638ee.vsu@altlinux.ru>
Date:	Sat, 10 Mar 2007 11:22:03 +0300
From:	Sergey Vlasov <vsu@...linux.ru>
To:	"Luong Ngo" <luong.ngo@...il.com>
Cc:	"Parav K Pandit" <parav_pandit@...dtree.com>,
	"Robert Hancock" <hancockr@...w.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>, tglx@...utronix.de
Subject: Re: Sleeping thread not receive signal until it wakes up

On Fri, 9 Mar 2007 16:10:29 -0800 Luong Ngo wrote:

> Thanks Parav, adding singal_allow(SIGALRM) wakeup the blocking
> interruptible_sleep_on and checking the signal_pending would return
> true now.

This means that there is also a bug in your userspace program -
somehow when it invokes ioctl(), it has SIGALRM blocked.  Use
sigprocmask() (or pthread_sigmask() if your program is multithreaded)
to ensure that SIGALRM is not blocked when you are expecting it to be
processed.  (Even if your program does not block SIGALRM, it may
inherit a blocked SIGALRM from another program which have started it,
so the safest way is to unblock SIGALRM explicitly.)

Using allow_signal() is needed only if you create a kernel thread and
want that thread to handle signals.

> But a quick question is when detecting signal_pending, I
> return -ERESTARTSYS, but the user process receive the return value of
> ioctl call is -1, shouldn't it be -4 for EINTR?

This is handled by syscall wrappers in libc - when the kernel returns
an error code from a syscall, the syscall wrapper function puts the
code into the per-thread errno variable and returns -1 to its caller.
Your userspace code should check errno for the actual error code when
it receives -1 from ioctl().

And the ERESTARTSYS error is really special - it never actually gets
returned to the userspace program; instead, the syscall return code in
the kernel catches it and either restarts the syscall after the signal
handler completes, or converts the error code to EINTR; one of these
actions is selected by the SA_RESTART flag to sigaction().

Content of type "application/pgp-signature" skipped