public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yong Zhang <yong.zhang0@gmail.com>
To: Hillf Danton <dhillf@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix unsafe operation in high resolution timer
Date: Sat, 25 Dec 2010 10:12:09 +0800	[thread overview]
Message-ID: <20101225021209.GA11183@zhy> (raw)
In-Reply-To: <AANLkTimc0FwBhj5MsnibTTq94AgaQgqCKEXNSOvM_XjE@mail.gmail.com>

On Fri, Dec 24, 2010 at 10:28:52PM +0800, Hillf Danton wrote:
> On Fri, Dec 24, 2010 at 3:17 PM, Yong Zhang <yong.zhang0@gmail.com> wrote:
> > On Thu, Dec 23, 2010 at 9:29 PM, Hillf Danton <dhillf@gmail.com> wrote:
> >> After calling the callback function of hrtimer, the timer could become
> >> unreliable in corner cases where the timer will no longer be queued
> >> and the mm segment, in which the timer is embedded, could be reclaimed
> >> in the callback.
> >>
> >> The unreliability is fixed by checking the result of callback before
> >> operating the timer again.
> >
> > Though the patch is buggy. But it actually explores a real problem.
> >
> 
> Would you please finger out why the patch is buggy?

No problem.

Actually the patch change the behavior of current hrtimer.
See comments below :)

> >> ---
> >>
> >> --- a/kernel/hrtimer.c  2010-11-01 19:54:12.000000000 +0800
> >> +++ b/kernel/hrtimer.c  2010-12-23 21:17:02.000000000 +0800
> >> @@ -1225,6 +1225,7 @@ static void __run_hrtimer(struct hrtimer
> >>        raw_spin_unlock(&cpu_base->lock);
> >>        trace_hrtimer_expire_entry(timer, now);
> >>        restart = fn(timer);
> >> +       if (restart != HRTIMER_NORESTART)
> >>        trace_hrtimer_expire_exit(timer);
> >>        raw_spin_lock(&cpu_base->lock);
> >>
> >> @@ -1236,11 +1237,8 @@ static void __run_hrtimer(struct hrtimer
> >>        if (restart != HRTIMER_NORESTART) {
> >>                BUG_ON(timer->state != HRTIMER_STATE_CALLBACK);
> >>                enqueue_hrtimer(timer, base);
> >> +               timer->state &= ~HRTIMER_STATE_CALLBACK;

HRTIMER_STATE_CALLBACK is only cleared for RESTART hrtimer with
your modification.

> >>        }
> >> -
> >> -       WARN_ON_ONCE(!(timer->state & HRTIMER_STATE_CALLBACK));
> >> -
> >> -       timer->state &= ~HRTIMER_STATE_CALLBACK;

But for a hrtimer which is not free in its callback, like a
static defined one. the hrtimer could be referenced at the same
time. So here you cann't just delete the two lines.

Thanks,
Yong

  reply	other threads:[~2010-12-25  2:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-23 13:29 [PATCH] fix unsafe operation in high resolution timer Hillf Danton
2010-12-24  7:17 ` Yong Zhang
2010-12-24 14:28   ` Hillf Danton
2010-12-25  2:12     ` Yong Zhang [this message]
2010-12-25 14:19       ` Hillf Danton
2010-12-26 13:12         ` Yong Zhang
2010-12-27 13:12           ` Hillf Danton
2010-12-29 15:43           ` Hillf Danton

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=20101225021209.GA11183@zhy \
    --to=yong.zhang0@gmail.com \
    --cc=dhillf@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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