lkml.org 
[lkml]   [2007]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: RFC/patch: down_timeout_interruptible()
Date
From
>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/

\
 
 \ /
  Last update: 2007-02-26 07:41    [W:0.045 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site