linux-kernel - RE: RFC/patch: down_timeout

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <C72DEB015BA7724783363DE1AF6B0F98016FF09B@orsmsx417.amr.corp.intel.com>
Date:	Sun, 25 Feb 2007 22:37:40 -0800
From:	"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@...el.com>
To:	"Arjan van de Ven" <arjan@...radead.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: RFC/patch: down_timeout_interruptible()

>From: Arjan van de Ven [mailto:arjan@...radead.org]
>
>> I gave it a quick try (must admit, not too tested) and it seems that
>> the setting of TIF_SIGPENDING without really having a signal queued
>> is not having easily visible ugly consequences.
>
>what happens if you get a signal around the time the timeout fires?

Depends of what around means.

+	result = down_interruptible(sem);
+	del_timer(&dit_timer);
+	if (result < 0 && data.result < 0)
+		result = data.result;

This piece of code will catch the 'timeout arrived right before a 
signal' case. 'data.result' is set by the timeout handler, so it 
doesn't interfere.

Now, if the timeout arrives right after a signal was delivered
but before the thread returns from down_interruptible, then it
will also look like a timeout (as that code in the if statement
will kick in) -- to some extent, it is 'right' theoretically, as
it didn't get the sem before the time expired. TIF_SIGPENDING is 
still set, so the signal is not lost (unless I miss something else
about the signal delivery engine).

The last case, if the timeout arrives after the signal and after
down_interruptible returns, nothing in theory. There is a window
where the timer could still execute before it is deleted and it
would look like a timeout [which theoretically could be right too].
Maybe the result < 0 && data.result < 0 check should be done 
before del_timer(). 

Suggestions? 

-- Inaky
-
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/