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
next prev parent 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