From: David Howells <dhowells@redhat.com>
To: Nicolas Pitre <nico@cam.org>
Cc: dhowells@redhat.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
torvalds@osdl.org, akpm@linux-foundation.org,
linux-am33-list@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] MN10300: Move asm-arm/cnt32_to_63.h to include/linux/
Date: Wed, 01 Oct 2008 15:34:10 +0100 [thread overview]
Message-ID: <29968.1222871650@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0809282123100.3635@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> Disabling preemption is unneeded.
I think you may be wrong on that. MEI came up with the following point:
I think either disable preemption or disable interrupt is really
necessary for cnt32_to_63 macro, because there seems to be assumption
that the series of the code (1)-(4) must be executed within a half
period of the 32-bit counter.
-------------------------------------------------
#define cnt32_to_63(cnt_lo)
({
static volatile u32 __m_cnt_hi = 0;
cnt32_to_63_t __x;
(1) __x.hi = __m_cnt_hi;
(2) __x.lo = (cnt_lo);
(3) if (unlikely((s32)(__x.hi ^ __x.lo) < 0))
(4) __m_cnt_hi = __x.hi = (__x.hi ^ 0x80000000) + (__x.hi >> 31);
__x.val;
})
-------------------------------------------------
If a task is preempted while executing the series of the code and
scheduled again after the half period of the 32-bit counter, the task
may destroy __m_cnt_hi.
Their suggested remedy is:
So I think it's better to disable interrupt the cnt32_to_63 and to
ensure that the series of the code are executed within a short period.
I think this is excessive... If we're sat there with interrupts disabled for
more than a half period (65s) then we've got other troubles. I think
disabling preemption for the duration ought to be enough. What do you think?
Now, I'm happy to put these in sched_clock() rather then cnt32_to_63() for my
purposes (see attached patch).
David
---
MN10300: Prevent cnt32_to_63() from being preempted in sched_clock()
From: David Howells <dhowells@redhat.com>
Prevent cnt32_to_63() from being preempted in sched_clock() because it may
read its internal counter, get preempted, get delayed for more than the half
period of the 'TSC' and then write the internal counter, thus corrupting it.
Whilst some callers of sched_clock() have interrupts disabled or hold
spinlocks, not all do, and so preemption must be held here.
Note that sched_clock() is called from lockdep, but that shouldn't be a problem
because although preempt_disable() calls into lockdep, lockdep has a recursion
counter to deal with this.
Signed-off-by: David Howells <dhowells@redhat.com>
---
arch/mn10300/kernel/time.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/mn10300/kernel/time.c b/arch/mn10300/kernel/time.c
index e460658..38f88bb 100644
--- a/arch/mn10300/kernel/time.c
+++ b/arch/mn10300/kernel/time.c
@@ -55,6 +55,9 @@ unsigned long long sched_clock(void)
unsigned long tsc, tmp;
unsigned product[3]; /* 96-bit intermediate value */
+ /* cnt32_to_63() is not safe with preemption */
+ preempt_disable();
+
/* read the TSC value
*/
tsc = 0 - get_cycles(); /* get_cycles() counts down */
@@ -65,6 +68,8 @@ unsigned long long sched_clock(void)
*/
tsc64.ll = cnt32_to_63(tsc) & 0x7fffffffffffffffULL;
+ preempt_enable();
+
/* scale the 64-bit TSC value to a nanosecond value via a 96-bit
* intermediate
*/
next prev parent reply other threads:[~2008-10-01 14:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 16:48 [PATCH 1/2] MN10300: Move asm-arm/cnt32_to_63.h to include/linux/ David Howells
2008-09-24 16:48 ` [PATCH 2/2] MN10300: Make sched_clock() report time since boot David Howells
2008-09-26 10:58 ` Peter Zijlstra
2008-09-26 10:56 ` [PATCH 1/2] MN10300: Move asm-arm/cnt32_to_63.h to include/linux/ Peter Zijlstra
2008-09-26 12:03 ` Nicolas Pitre
2008-09-26 12:08 ` Peter Zijlstra
2008-09-29 1:21 ` Nicolas Pitre
2008-09-26 12:20 ` Peter Zijlstra
2008-09-29 1:42 ` Nicolas Pitre
2008-10-01 14:34 ` David Howells [this message]
2008-10-01 15:36 ` Nicolas Pitre
2008-10-02 22:23 ` David Howells
2008-10-03 19:15 ` Nicolas Pitre
2008-10-06 10:44 ` David Howells
2008-10-06 15:06 ` Nicolas Pitre
2008-09-26 13:27 ` David Howells
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=29968.1222871650@redhat.com \
--to=dhowells@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-am33-list@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@cam.org \
--cc=torvalds@osdl.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 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).