Messages in this thread | | | Date | Thu, 13 Jan 2005 09:58:27 -0800 | From | Nish Aravamudan <> | Subject | Re: Kernel conector. Reincarnation #1. |
| |
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 - 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/
| |