linux-kernel - Likely race between sys_rt_sigtimedwait() and complete

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 for Android: free password hash cracker in your pocket

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

Message-Id: <201102101032.16401@blacky.localdomain>
Date:	Thu, 10 Feb 2011 10:32:16 +0300
From:	"Nikita V. Youshchenko" <nyoushchenko@...sta.com>
To:	linux-kernel@...r.kernel.org
Cc:	Alexander Kaliadin <akaliadin@...sta.com>, oishi.y@....yzk.co.jp
Subject: Likely race between sys_rt_sigtimedwait() and complete_signal()

Hello linux-kernel.

Within project we are working on, we are facing a "rare" situation when 
setitimer() / sigwait() - based periodic task execution hangs. "Rare" 
means once per several hours for 1000 Hz timer.

For hanged thread, cat /proc/pid/status shows

...
State:	S (sleeping)
...
SigPnd:	0000000000000000
ShdPnd:	0000000000002000
SigBlk:	0000000000000000
...

and SysRq - T shows

[<c015b1b0>] (__schedule+0x2fc/0x37c) from [<c015b7b8>] 
(schedule+0x1c/0x30)
[<c015b7b8>] (schedule+0x1c/0x30) from [<c015b8c4>] 
(schedule_timeout+0x18/0x1dc)
[<c015b8c4>] (schedule_timeout+0x18/0x1dc) from [<c004a084>] 
(sys_rt_sigtimedwait+0x1b4/0x288)
[<c004a084>] (sys_rt_sigtimedwait+0x1b4/0x288) from [<c001cf00>] 
(ret_fast_syscall+0x0/0x28)

All other threads have SIGALRM blocked as they should, looking 
through /proc/X/status proves this.

So for some reason, SIGALRM was successfully delivered by timer, bit was 
set in ShdPnd [I guess at the bottom of __send_signal()], but that still 
resulted somehow in thread going to schedule() and not waking.

I guess this is some sort of race between sys_rt_sigtimedwait() and 
complete_signal().

This is on embedded system running vendor 2.6.31-based kernel, moving 
forward is unfortunately impossible because of hardware support issues. 
However I've looked through

git log -p HEAD..linus/master -- kernel/signal.c

and did not notice anything that could be related.

Unfortunately we don't currently have resources for futher analysis - 
especially with simple workarounds existing, such as switch to 
timerfd-based periodic execution (which looks working without hangs).

However I guess the race we faced still exists in the current upstream 
kernel, so maybe somebody on this mailing list could be interested into 
looking at this?

Nikita
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/