On Thu, 2005-01-13 at 09:58 -0800, Nish Aravamudan wrote:
> 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.

Ok, updated patch attached.
Thank you.

> Thanks,
> Nish
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski