RFC/patch: down_timeout_interruptible()

RFC/patch: down_timeout_interruptible()

[Iñaky Pérez-González]

Hi All

I was in a situation where I could really simplify many things by
using down_interruptible() with a timeout. I went around looking for
how could one be implemented and ran away from the asm code in arch/.

At the end I realized I could make a simple one by setting up a timer
that would 'fake' a sigpending situation (setting the task's TIF_SIGPENDING
bit) so that the __down_interruptible_failed() path would quit when 
the timer went off.

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.

Does anybody have suggestions on how to alternatively implement this?

Thanks,

-- Inaky


 include/asm-i386/semaphore.h |    3 ++
 lib/semaphore-sleepers.c     |   51 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+)

diff -r 9ed3c4dc013f include/asm-i386/semaphore.h
--- a/include/asm-i386/semaphore.h	Wed Feb 21 13:02:17 2007 -0800
+++ b/include/asm-i386/semaphore.h	Thu Feb 22 17:09:13 2007 -0800
@@ -88,6 +88,9 @@ fastcall int  __down_failed_interruptibl
 fastcall int  __down_failed_interruptible(void  /* params in registers */);
 fastcall int  __down_failed_trylock(void  /* params in registers */);
 fastcall void __up_wakeup(void /* special register calling convention */);
+/* FIXME: need to add to other header files */
+extern void down_timeout_interruptible(struct semaphore *);
+
 
 /*
  * This is ugly, but we want the default case to fall through.
diff -r 9ed3c4dc013f lib/semaphore-sleepers.c
--- a/lib/semaphore-sleepers.c	Wed Feb 21 13:02:17 2007 -0800
+++ b/lib/semaphore-sleepers.c	Thu Feb 22 16:52:54 2007 -0800
@@ -174,3 +174,54 @@ fastcall int __down_trylock(struct semap
 	spin_unlock_irqrestore(&sem->wait.lock, flags);
 	return 1;
 }
+
+
+struct dit_data 
+{
+	struct task_struct *task;
+	int result;
+};
+
+/**
+ * dit_kick_process - set a fake 'signal pending' and kick
+ *
+ * Helper for down_interruptible_timeout(). Sets the signal pending
+ * flag on the task that is waiting for a semaphore and kicks it. That
+ * tells the down_interruptible() code to quit waiting.
+ */
+static 
+void dit_kick_process(unsigned long _data)
+{
+	struct dit_data *data = (void *) _data;
+	set_tsk_thread_flag(data->task, TIF_SIGPENDING);
+	data->result = -ETIMEDOUT;
+	kick_process(data->task);
+}
+
+
+/*
+ * Interruptible try to acquire a semaphore.  If we obtained
+ * it, return zero.  If we were interrupted, returns -EINTR. If we
+ * timedout, we return -ETIMEDOUT;
+ *
+ * Note the ugly hack, using a helper timer and function to wake up
+ * the waiter. We need to distinguish, if we get an error, if it was
+ * because we were woken up (-ETIMEDOUT) or for other reason (-EINTR),
+ * hence the last if block.
+ */
+int down_interruptible_timeout(struct semaphore *sem, unsigned long to) 
+{
+	int result;
+	struct dit_data data = {
+		.task = get_current(), .result = 0 
+	};
+	DEFINE_TIMER(dit_timer, dit_kick_process, to, (unsigned long) &data);
+	add_timer(&dit_timer);
+	result = down_interruptible(sem);
+	del_timer(&dit_timer);
+	if (result < 0 && data.result < 0)
+		result = data.result;
+	return result;
+}
+
+

Re: RFC/patch: down_timeout_interruptible()

[Arjan van de Ven]

> 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?

RE: RFC/patch: down_timeout_interruptible()

[Perez-Gonzalez, Inaky]

>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