From: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andreas Mohr <andi-5+Cda9B46AM@public.gmane.org>,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
tony.xie-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Subject: Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process()
Date: Tue, 11 Oct 2016 11:54:28 -0700 [thread overview]
Message-ID: <20161011185427.GA18048@localhost> (raw)
In-Reply-To: <1476133442-17757-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Hi Doug,
On Mon, Oct 10, 2016 at 02:04:02PM -0700, Doug Anderson wrote:
> 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.
Like you and Andreas, I also don't understand Thomas's objection to your
above claim on what users of this function expect. I believe you have
clearly laid out why the current behavior needs to be changed somehow;
IMO the only remaining question is "how." Your follow up covers all this
plenty well for me.
Either we need a fix along the lines of what you've proposed, or else we
need to completely rethink almost all uses of usleep_range().
...
> Reported-by: Tao Huang <huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> Changes in v2:
> - Fixed stupid bug that snuck in before posting
> - Use ktime_before
> - Remove delta from the loop
>
> NOTE: Tested against 4.4 tree w/ backports. I'm trying to get myself
> up and running with mainline again to test there now but it might be a
> little while. Hopefully this time I don't shoot myself in the foot.
>
> kernel/time/timer.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
I've reviewed the logic here to the best of my ability, and it looks
good to me now. I'll admit that I'm not really a timekeeping or
scheduler expert, but FWIW:
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 32bf6f75a8fe..219439efd56a 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1898,12 +1898,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));
> }
>
> /**
> --
> 2.8.0.rc3.226.g39d4020
>
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
John Stultz <john.stultz@linaro.org>,
Andreas Mohr <andi@lisas.de>,
huangtao@rock-chips.com, tony.xie@rock-chips.com,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process()
Date: Tue, 11 Oct 2016 11:54:28 -0700 [thread overview]
Message-ID: <20161011185427.GA18048@localhost> (raw)
In-Reply-To: <1476133442-17757-1-git-send-email-dianders@chromium.org>
Hi Doug,
On Mon, Oct 10, 2016 at 02:04:02PM -0700, Doug Anderson wrote:
> 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.
Like you and Andreas, I also don't understand Thomas's objection to your
above claim on what users of this function expect. I believe you have
clearly laid out why the current behavior needs to be changed somehow;
IMO the only remaining question is "how." Your follow up covers all this
plenty well for me.
Either we need a fix along the lines of what you've proposed, or else we
need to completely rethink almost all uses of usleep_range().
...
> Reported-by: Tao Huang <huangtao@rock-chips.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Changes in v2:
> - Fixed stupid bug that snuck in before posting
> - Use ktime_before
> - Remove delta from the loop
>
> NOTE: Tested against 4.4 tree w/ backports. I'm trying to get myself
> up and running with mainline again to test there now but it might be a
> little while. Hopefully this time I don't shoot myself in the foot.
>
> kernel/time/timer.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
I've reviewed the logic here to the best of my ability, and it looks
good to me now. I'll admit that I'm not really a timekeeping or
scheduler expert, but FWIW:
Reviewed-by: Brian Norris <briannorris@chromium.org>
> diff --git a/kernel/time/timer.c b/kernel/time/timer.c
> index 32bf6f75a8fe..219439efd56a 100644
> --- a/kernel/time/timer.c
> +++ b/kernel/time/timer.c
> @@ -1898,12 +1898,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));
> }
>
> /**
> --
> 2.8.0.rc3.226.g39d4020
>
next prev parent reply other threads:[~2016-10-11 18:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-10 21:04 [PATCH v2] timers: Fix usleep_range() in the context of wake_up_process() Douglas Anderson
2016-10-10 21:04 ` Douglas Anderson
2016-10-10 22:39 ` Doug Anderson
2016-10-11 7:14 ` Thomas Gleixner
2016-10-11 16:33 ` Doug Anderson
2016-10-12 8:56 ` Mark Brown
2016-10-12 8:56 ` Mark Brown
2016-10-11 18:25 ` Andreas Mohr
2016-10-11 18:25 ` Andreas Mohr
[not found] ` <20161011182541.GA32165-p/qQFhXj4MHA4IYVXhSI5GHfThorsUsI@public.gmane.org>
2016-10-12 13:11 ` Thomas Gleixner
2016-10-12 13:11 ` Thomas Gleixner
2016-10-12 17:39 ` Doug Anderson
2016-10-11 20:34 ` Heiko Stuebner
2016-10-11 20:34 ` Heiko Stuebner
[not found] ` <1476133442-17757-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2016-10-11 18:54 ` Brian Norris [this message]
2016-10-11 18:54 ` Brian Norris
2016-10-11 19:30 ` Andreas Mohr
2016-10-11 19:30 ` Andreas Mohr
[not found] ` <20161011193034.GA10646-p/qQFhXj4MHA4IYVXhSI5GHfThorsUsI@public.gmane.org>
2016-10-11 20:02 ` Doug Anderson
2016-10-11 20:02 ` Doug Anderson
[not found] ` <CAD=FV=Ua8c18SGr54ThmVe1oR3bqfCyHxfhL=6z8vJXkMiUedA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-11 20:40 ` Andreas Mohr
2016-10-11 20:40 ` Andreas Mohr
2016-10-12 16:03 ` [v2] " Guenter Roeck
2016-10-12 16:03 ` Guenter Roeck
[not found] ` <20161012160309.GA19146-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2016-10-12 16:27 ` Doug Anderson
2016-10-12 16:27 ` Doug Anderson
[not found] ` <CAD=FV=Ug9P1XDvF-Z_gPeU4CtFzoXQZuy7rmdg4FNGFdT77ENQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-12 16:53 ` Guenter Roeck
2016-10-12 16:53 ` Guenter Roeck
2016-10-18 13:44 ` [PATCH v2] " Daniel Kurtz
2016-10-18 20:29 ` Doug Anderson
2016-10-20 8:57 ` Daniel Kurtz
2016-10-20 9:51 ` Thomas Gleixner
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=20161011185427.GA18048@localhost \
--to=briannorris-f7+t8e8rja9g9huczpvpmw@public.gmane.org \
--cc=andi-5+Cda9B46AM@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=tony.xie-TNX95d0MmH7DzftRWevZcw@public.gmane.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.