All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] sys_epoll ...
Date: Sun, 20 Oct 2002 19:01:20 -0700	[thread overview]
Message-ID: <3DB35FF0.1E967894@digeo.com> (raw)
In-Reply-To: Pine.LNX.4.44.0210201853460.959-100000@blue1.dev.mcafeelabs.com

Davide Libenzi wrote:
> 
> On Sun, 20 Oct 2002, Andrew Morton wrote:
> 
> > +                       if (ep->eventcnt || !timeout)
> > +                               break;
> > +                       if (signal_pending(current)) {
> > +                               res = -EINTR;
> > +                               break;
> > +                       }
> > +
> > +                       set_current_state(TASK_INTERRUPTIBLE);
> > +
> > +                       write_unlock_irqrestore(&ep->lock, flags);
> > +                       timeout = schedule_timeout(timeout);
> >
> > You should set current->state before performing the checks.
> 
> Why this Andrew ?
> 

Well I'm assuming that you don't want to sleep if, say,
ep->eventcnt is non-zero.  The code is currently (simplified):

	add_wait_queue(...);
	if (ep->eventcnt)
		break;
	/* window here */
	set_current_state(TASK_INTERRUPTIBLE);
	schedule();

If another CPU increments eventcnt and sends this task a wakeup in that
window, it is missed and we still sleep.  The conventional fix for that
is:

	add_wait_queue(...);
	set_current_state(TASK_INTERRUPTIBLE);
	if (ep->eventcnt)
		break;
	/* harmless window here */
	schedule();

So if someone delivers a wakeup in the "harmless window" then this task
still calls schedule(), but the wakeup has turned the state from
TASK_INTERRUPTIBLE into TASK_RUNNING, so the schedule() doesn't actually
take this task off the runqueue.  This task will zoom straight through the
schedule() and will then loop back and notice the incremented ep->eventcnt.

So it is important that the waker increment eventcnt _before_ delivering
the wake_up, too.

  reply	other threads:[~2002-10-21  1:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-21  0:16 [patch] sys_epoll Davide Libenzi
2002-10-21  0:50 ` Andrew Morton
2002-10-21  1:28   ` Davide Libenzi
2002-10-21  1:54   ` Davide Libenzi
2002-10-21  2:01     ` Andrew Morton [this message]
2002-10-21  2:18       ` Davide Libenzi
2002-10-21  3:34   ` Davide Libenzi
  -- strict thread matches above, loose matches on Subject: below --
2002-10-21  7:05 Dan Kegel
2002-10-21 17:10 ` Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DB35FF0.1E967894@digeo.com \
    --to=akpm@digeo.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.