[PATCH, RFC 28/30] sgi-xp: open-code interruptible_sleep_on_timeout

From: Arnd Bergmann
Date: Thu Jan 02 2014 - 07:10:05 EST


interruptible_sleep_on_timeout is deprecated and going away soon.
The use in the sgi-xp driver leaves me puzzled, so I'd prefer not
to touch it. This patch replaces it with an open-coded prepare_to_wait
and finish_wait pair, which should be completely equivalent, so it
doesn't fix an existing race, but lets us get away with removing
the function so we can not get any new users.

In order to remove the typical sleep_on race, one would have to
replace the call with wait_event_interruptible_timeout and add
a condition to wait for. The fact that there is a one-jiffy timeout
suggests that we don't actually expect to get woken up properly
and the caller just uses this as a short sleeping function
if it doesn't wake up properly.

Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
Cc: Cliff Whickman <cpw@xxxxxxx>
Cc: Robin Holt <robinmholt@xxxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/misc/sgi-xp/xpc_channel.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/sgi-xp/xpc_channel.c b/drivers/misc/sgi-xp/xpc_channel.c
index 652593f..128d561 100644
--- a/drivers/misc/sgi-xp/xpc_channel.c
+++ b/drivers/misc/sgi-xp/xpc_channel.c
@@ -828,6 +828,7 @@ enum xp_retval
xpc_allocate_msg_wait(struct xpc_channel *ch)
{
enum xp_retval ret;
+ DEFINE_WAIT(wait);

if (ch->flags & XPC_C_DISCONNECTING) {
DBUG_ON(ch->reason == xpInterrupted);
@@ -835,7 +836,9 @@ xpc_allocate_msg_wait(struct xpc_channel *ch)
}

atomic_inc(&ch->n_on_msg_allocate_wq);
- ret = interruptible_sleep_on_timeout(&ch->msg_allocate_wq, 1);
+ prepare_to_wait(&ch->msg_allocate_wq, &wait, TASK_INTERRUPTIBLE);
+ ret = schedule_timeout(1);
+ finish_wait(&ch->msg_allocate_wq, &wait);
atomic_dec(&ch->n_on_msg_allocate_wq);

if (ch->flags & XPC_C_DISCONNECTING) {
--
1.8.3.2

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