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: <20070307210903.0988be8f.vsu@altlinux.ru>
Date:	Wed, 7 Mar 2007 21:09:03 +0300
From:	Sergey Vlasov <vsu@...linux.ru>
To:	"Luong Ngo" <luong.ngo@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Sleeping thread not receive signal until it wakes up

On Tue, 6 Mar 2007 21:31:37 -0800 Luong Ngo wrote:

> I am having this problem. I have a process with 2 threads created. One
> of the thread will keep calling IOCTL  to get information from the
> kernel and will be blocked if there is no new information. If there is
> information retured, the thread will be checked to see if any error
> happens and trigger an action. Since we have no way to know if the
> error is gone (Hardware provides no signal), so what we do is when
> trigger an action for the error, we will set an timer using alarm()
> and register a SIGALRM handler in the thread by using sigaction. After
> setting the alarm, the thread will loop back and call IOCTL, which
> could cause it to be put to sleep. The problem is the SIGALRM handler
> does not receive the SIGALRM while the thread is being blocked by
> IOCTL. And if we generated some event so that the IOCTL is returned
> with new information, the SIGALRM handler is invoked right away.
> However, as I read the manual, which says a thread/process should be
> waken up even when it sleeps if there is a signal delivered to it. Am
> I right?

Probably the ioctl handler of the driver you are calling does not use
interruptible sleeps, therefore it cannot be interrupted by a signal.
In this case you need to fix the driver to use interruptible sleeps
and return -ERESTARTSYS when some signal is pending.

Content of type "application/pgp-signature" skipped