linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Shawn Bohrer <shawn.bohrer@gmail.com>
Cc: Jack Stone <jwjstone@fastmail.fm>,
	Viresh Kumar <viresh.kumar@st.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	viro@zeniv.linux.org.uk
Subject: Re: [PATCH resend] fs/eventpoll.c: fix compilation warning
Date: Fri, 14 Jan 2011 16:05:08 -0800	[thread overview]
Message-ID: <20110114160508.41105533.akpm@linux-foundation.org> (raw)
In-Reply-To: <AANLkTikQwgzTZrTVQ_kfxwNdT-_8Ly5FjCxiXB2gxj3W@mail.gmail.com>

On Fri, 14 Jan 2011 08:48:11 -0600
Shawn Bohrer <shawn.bohrer@gmail.com> wrote:

> On Fri, Jan 14, 2011 at 7:07 AM, Jack Stone <jwjstone@fastmail.fm> wrote:
> > [cc Al Viro and Shawn Bohrer]
> > On 14/01/2011 11:52, Viresh Kumar wrote:
> >> This patch fixes following compilation warning
> >> fs/eventpoll.c:1119: warning: 'slack' may be used uninitialized in this function
> >>
> >> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> >> ---
> >>  fs/eventpoll.c |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> >> index 8cf0724..89b5e98 100644
> >> --- a/fs/eventpoll.c
> >> +++ b/fs/eventpoll.c
> >> @@ -1116,7 +1116,7 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event  user *events,
> >>  {
> >>       int res, eavail, timed_out = 0;
> >>       unsigned long flags;
> >> -     long slack;
> >> +     long uninitialized_var(slack);
> >>       wait_queue_t wait;
> >>       struct timespec end_time;
> >>       ktime_t expires, *to = NULL;
> >
> > Hi Viresh,
> >
> > This is certainly the correct thing to do if timeout cannot be negative.
> >
> > Al, Shawn
> >
> > Can timeout be negative, and if so what does it mean?
> 
> Yes timeout can be negative.  When timeout is negative it signifies an
> infinite timeout.  Therefore I think the correct fix is to initialize
> slack to 0.  I actually sent a patch to fix this back in November, but
> it looks like it was never applied.
> 
> https://lkml.org/lkml/2010/11/27/143
> 
> Andrew, can you apply this patch?  Let me know if I need to resend.

I've looked at this warning several times - the code is non-buggy and
it's a bit sad to add extra instructions unnecessarily.  It would be
better to make this warning go away by cleaning up or restructuring the
code.  

And the code _is_ pretty stupid.  If timed_out is set to 1 then the
function does a great pile of useless junk.  I had a quick tinkle, made
things worse and gave up:

--- a/fs/eventpoll.c~a
+++ a/fs/eventpoll.c
@@ -1124,16 +1124,20 @@ static int ep_poll(struct eventpoll *ep,
 	struct timespec end_time;
 	ktime_t expires, *to = NULL;
 
-	if (timeout > 0) {
-		ktime_get_ts(&end_time);
-		timespec_add_ns(&end_time, (u64)timeout * NSEC_PER_MSEC);
-		slack = select_estimate_accuracy(&end_time);
-		to = &expires;
-		*to = timespec_to_ktime(end_time);
-	} else if (timeout == 0) {
-		timed_out = 1;
+	if (timeout == 0) {
+		/*
+		 * explanation of what timeout==0 means goes here
+		 */
+		spin_lock_irqsave(&ep->lock, flags);
+		goto skip;
 	}
 
+	ktime_get_ts(&end_time);
+	timespec_add_ns(&end_time, (u64)timeout * NSEC_PER_MSEC);
+	slack = select_estimate_accuracy(&end_time);
+	to = &expires;
+	*to = timespec_to_ktime(end_time);
+
 retry:
 	spin_lock_irqsave(&ep->lock, flags);
 
@@ -1149,9 +1153,10 @@ retry:
 
 		for (;;) {
 			/*
-			 * We don't want to sleep if the ep_poll_callback() sends us
-			 * a wakeup in between. That's why we set the task state
-			 * to TASK_INTERRUPTIBLE before doing the checks.
+			 * We don't want to sleep if the ep_poll_callback()
+			 * sends us a wakeup in between. That's why we set the
+			 * task state to TASK_INTERRUPTIBLE before doing the
+			 * checks.
 			 */
 			set_current_state(TASK_INTERRUPTIBLE);
 			if (!list_empty(&ep->rdllist) || timed_out)
@@ -1171,6 +1176,7 @@ retry:
 
 		set_current_state(TASK_RUNNING);
 	}
+skip:
 	/* Is it worth to try to dig for events ? */
 	eavail = !list_empty(&ep->rdllist) || ep->ovflist != EP_UNACTIVE_PTR;
 
_


but you get the idea ;)

I think the attempt to munge the "timeout==0" spacial case into the
main body of the polling loop was a mistake, and that the code would be
better/cleaner if that special case was handled quite separately.


  parent reply	other threads:[~2011-01-15  0:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-14 11:52 [PATCH resend] fs/eventpoll.c: fix compilation warning Viresh Kumar
2011-01-14 13:07 ` Jack Stone
2011-01-14 14:48   ` Shawn Bohrer
2011-01-14 15:21     ` Davide Libenzi
2011-01-15  0:05     ` Andrew Morton [this message]
2011-01-15 11:10       ` Jack Stone
2011-01-15 16:20       ` Shawn Bohrer
2011-01-15 17:00         ` [PATCH 1/3] epoll: initialize slack for negative timeout values Shawn Bohrer
2011-01-15 19:06           ` Davide Libenzi
2011-03-18  7:38           ` Mike Frysinger
2011-01-15 17:00         ` [PATCH 2/3] epoll: short circuit the timeout==0 case Shawn Bohrer
2011-01-15 17:00         ` [PATCH 3/3] epoll: remove unnecessary test of ep->ovflist for available events Shawn Bohrer
2011-01-15 19:03           ` 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=20110114160508.41105533.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=jwjstone@fastmail.fm \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shawn.bohrer@gmail.com \
    --cc=viresh.kumar@st.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).