RE: RFC/patch: down_timeout_interruptible()

["Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>]

>From: Arjan van de Ven [mailto:arjan@infradead.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/