FROMLIST: timers: Fix usleep_range() in the context of wake_up_process()
authorDouglas Anderson <dianders@chromium.org>
Mon, 10 Oct 2016 21:04:02 +0000 (14:04 -0700)
committerHuang, Tao <huangtao@rock-chips.com>
Wed, 12 Oct 2016 02:34:40 +0000 (10:34 +0800)
Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter.  However, nothing in any of the code
ensures this.  Specifically:

usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer.  If someone else happens to
wake up our task then we'll happily return from usleep_range() early.

msleep() already has code to handle this case since it will loop as long
as there was still time left.  usleep_range() had no such loop.

The problem is is easily demonstrated with a small bit of test code:

  static int usleep_test_task(void *data)
  {
    atomic_t *done = data;
    ktime_t start, end;

    start = ktime_get();
    usleep_range(50000, 100000);
    end = ktime_get();
    pr_info("Requested 50000 - 100000 us.  Actually slept for %llu us\n",
      (unsigned long long)ktime_to_us(ktime_sub(end, start)));
    atomic_set(done, 1);

    return 0;
  }

  static void run_usleep_test(void)
  {
    struct task_struct *t;
    atomic_t done;

    atomic_set(&done, 0);

    t = kthread_run(usleep_test_task, &done, "usleep_test_task");
    while (!atomic_read(&done)) {
      wake_up_process(t);
      udelay(1000);
    }
    kthread_stop(t);
  }

If you run the above code without this patch you get things like:
  Requested 50000 - 100000 us.  Actually slept for 967 us

If you run the above code _with_ this patch, you get:
  Requested 50000 - 100000 us.  Actually slept for 50001 us

Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
  usleep_range().
- There aren't lots of places that use usleep_range(), since many people
  call either msleep() or udelay().

Change-Id: Ibb93ce0dd9fb9688d4a8d10447c098c1dfbd7a1d
Reported-by: Tao Huang <huangtao@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Andreas Mohr <andim2@users.sf.net>
(am from https://patchwork.kernel.org/patch/9369963/)

kernel/time/timer.c

index d1798fa0c7432527cb5bde3f99455b0c28bce068..a5f643d82df01279b8185a3ebde31f84c97da31d 100644 (file)
@@ -1697,12 +1697,28 @@ EXPORT_SYMBOL(msleep_interruptible);
 
 static void __sched do_usleep_range(unsigned long min, unsigned long max)
 {
+       ktime_t now, end;
        ktime_t kmin;
        u64 delta;
+       int ret;
 
-       kmin = ktime_set(0, min * NSEC_PER_USEC);
+       now = ktime_get();
+       end = ktime_add_us(now, min);
        delta = (u64)(max - min) * NSEC_PER_USEC;
-       schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+       do {
+               kmin = ktime_sub(end, now);
+               ret = schedule_hrtimeout_range(&kmin, delta, HRTIMER_MODE_REL);
+
+               /*
+                * If schedule_hrtimeout_range() returns 0 then we actually
+                * hit the timeout. If not then we need to re-calculate the
+                * new timeout ourselves.
+                */
+               if (ret == 0)
+                       break;
+
+               now = ktime_get();
+       } while (ktime_before(now, end));
 }
 
 /**