Re: Kernel conector. Reincarnation #1.

From: Nish Aravamudan
Date: Thu Jan 13 2005 - 13:04:13 EST


On Thu, 13 Jan 2005 00:16:11 +0300, Evgeniy Polyakov
<johnpol@xxxxxxxxxxx> wrote:
> Sorry, forget about nasty typo.
> Current one is right.

<snip>

> diff -Nru /tmp/empty/cn_queue.c linux-2.6.9/drivers/connector/cn_queue.c
> --- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.000000000 +0300
> +++ linux-2.6.9/drivers/connector/cn_queue.c 2005-01-12 23:23:45.000000000 +0300

<snip>

> + while (atomic_read(&cbq->cb->refcnt)) {
> + printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n",
> + cbq->pdev->name, atomic_read(&cbq->cb->refcnt));
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ);
> +
> + if (current->flags & PF_FREEZE)
> + refrigerator(PF_FREEZE);
> +
> + if (signal_pending(current))
> + flush_signals(current);
> + }

<snip>

> + while (atomic_read(&dev->refcnt)) {
> + printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n",
> + dev->name, atomic_read(&dev->refcnt));
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(HZ);
> +
> + if (current->flags & PF_FREEZE)
> + refrigerator(PF_FREEZE);
> +
> + if (signal_pending(current))
> + flush_signals(current);
> + }

Would it be possible to use msleep_interruptible(1000) in both of
these locations? You only seem to be concerned with signals (not
wait-queue events) and the time is rather long (1000 msec).
signals_pending(current) will still be true upon return from
msleep_interruptible(), so it's a minimal change, I think.

Thanks,
Nish
-
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/