Re: Kernel conector. Reincarnation #1.

[Nish Aravamudan <nish.aravamudan@gmail.com>]

On Thu, 13 Jan 2005 00:16:11 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> 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