lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080729223105.GK10982@flint.arm.linux.org.uk>
Date:	Tue, 29 Jul 2008 23:31:05 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	akpm@...ux-foundation.org, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Fwd: Commit 76a2a6ee8a0660a29127f05989ac59ae1ce865fa breaks PXA270 (at least)?

Sigh.  This is going to break virtually every ARM platform which
provides a high resolution sched_clock.

We've had this issue before when printk_clock was linked to sched_clock.

We worked around that breakage by defining our own printk_clock().
But then some bright spark thought it would be a good idea to get
rid of printk_clock().

If we want to couple the clock used by printk to sched_clock() by
default, can we please have printk_clock() back so ARM can provide
an implementation based solely upon jiffies, because basing it on
hardware sources Just Doesn't Work - the reason why...

... you can not access high resolution clocks because peripherals
are MMIO.  There's no standard high resolution clocks, so there's
no standard place to map.  And mappings are setup after the first
printk happens.

So, while we want to be able to use high resolution clocks for the
scheduler, the scheduler clock must _not_ be used for printk.

----- Forwarded message from Bill Gatliff <bgat@...lgatliff.com> -----

Delivery-date: Tue, 29 Jul 2008 23:21:39 +0100
Date: Sat, 26 Jul 2008 12:18:43 -0500
From: Bill Gatliff <bgat@...lgatliff.com>
To: linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Commit 76a2a6ee8a0660a29127f05989ac59ae1ce865fa breaks PXA270 (at
	least)?

Guys:


I'm tracking this git repo:

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

The commit 76a2a6ee8a0660a29127f05989ac59ae1ce865fa causes my PXA270
board to hang at boot.  If I surgically remove that change, things seem
to work fine.

I'm not quite sure what this patch is doing.  Anyone having similar
problems?



commit 76a2a6ee8a0660a29127f05989ac59ae1ce865fa
Author: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Date:   Fri Jun 27 13:41:15 2008 +0200

    sched: sched_clock_cpu() based cpu_clock()

    with sched_clock_cpu() being reasonably in sync between cpus (max 1
jiffy
    difference) use this to provide cpu_clock().

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
    Cc: Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
    Cc: Mike Galbraith <efault@....de>
    Signed-off-by: Ingo Molnar <mingo@...e.hu>

diff --git a/kernel/sched.c b/kernel/sched.c
index 874b6da..eb3454c 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -818,82 +818,6 @@ static inline u64 global_rt_runtime(void)
 	return (u64)sysctl_sched_rt_runtime * NSEC_PER_USEC;
 }

-unsigned long long time_sync_thresh = 100000;
-
-static DEFINE_PER_CPU(unsigned long long, time_offset);
-static DEFINE_PER_CPU(unsigned long long, prev_cpu_time);
-
-/*
- * Global lock which we take every now and then to synchronize
- * the CPUs time. This method is not warp-safe, but it's good
- * enough to synchronize slowly diverging time sources and thus
- * it's good enough for tracing:
- */
-static DEFINE_SPINLOCK(time_sync_lock);
-static unsigned long long prev_global_time;
-
-static unsigned long long __sync_cpu_clock(unsigned long long time, int
cpu)
-{
-	/*
-	 * We want this inlined, to not get tracer function calls
-	 * in this critical section:
-	 */
-	spin_acquire(&time_sync_lock.dep_map, 0, 0, _THIS_IP_);
-	__raw_spin_lock(&time_sync_lock.raw_lock);
-
-	if (time < prev_global_time) {
-		per_cpu(time_offset, cpu) += prev_global_time - time;
-		time = prev_global_time;
-	} else {
-		prev_global_time = time;
-	}
-
-	__raw_spin_unlock(&time_sync_lock.raw_lock);
-	spin_release(&time_sync_lock.dep_map, 1, _THIS_IP_);
-
-	return time;
-}
-
-static unsigned long long __cpu_clock(int cpu)
-{
-	unsigned long long now;
-
-	/*
-	 * Only call sched_clock() if the scheduler has already been
-	 * initialized (some code might call cpu_clock() very early):
-	 */
-	if (unlikely(!scheduler_running))
-		return 0;
-
-	now = sched_clock_cpu(cpu);
-
-	return now;
-}
-
-/*
- * For kernel-internal use: high-speed (but slightly incorrect) per-cpu
- * clock constructed from sched_clock():
- */
-unsigned long long cpu_clock(int cpu)
-{
-	unsigned long long prev_cpu_time, time, delta_time;
-	unsigned long flags;
-
-	local_irq_save(flags);
-	prev_cpu_time = per_cpu(prev_cpu_time, cpu);
-	time = __cpu_clock(cpu) + per_cpu(time_offset, cpu);
-	delta_time = time-prev_cpu_time;
-
-	if (unlikely(delta_time > time_sync_thresh)) {
-		time = __sync_cpu_clock(time, cpu);
-		per_cpu(prev_cpu_time, cpu) = time;
-	}
-	local_irq_restore(flags);
-
-	return time;
-}
-EXPORT_SYMBOL_GPL(cpu_clock);
-
 #ifndef prepare_arch_switch
 # define prepare_arch_switch(next)	do { } while (0)
 #endif
diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c
index ce05271..3c696db 100644
--- a/kernel/sched_clock.c
+++ b/kernel/sched_clock.c
@@ -244,3 +244,15 @@ unsigned long long __attribute__((weak))
sched_clock(void)
 {
 	return (unsigned long long)jiffies * (NSEC_PER_SEC / HZ);
 }
+
+unsigned long long cpu_clock(int cpu)
+{
+	unsigned long long clock;
+	unsigned long flags;
+
+	raw_local_irq_save(flags);
+	clock = sched_clock_cpu(cpu);
+	raw_local_irq_restore(flags);
+
+	return clock;
+}


-- 
Bill Gatliff
bgat@...lgatliff.com


-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

----- End forwarded message -----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ