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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 23 Feb 2007 14:03:28 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: radeon breaks with clocksource_jiffies

From: David Miller <davem@...emloft.net>
Date: Fri, 23 Feb 2007 13:45:05 -0800 (PST)

> While probeing PLL information via radeon_get_pllinfo(), it does a
> "gettimeofday(); do_something(); gettimeofday();" type sequence
> explicitly with interrupts disabled, so ends up with a zero
> measurement which then results in a bunch of divisions by zero.
> 
> We should decide whether gettimeofday() can be expected to advance with
> interrupts disabled, or that clocksource_jiffies is simply invalid because
> of this behavior.

Actually, with clocksource based gettimeofday(), radeon built-in cannot
work at all.

The reason is that the clocksource code will not jump over to a
clock source other than clocksource_jiffies until the late initcalls
are run, because of this code:

/* clocksource_done_booting - Called near the end of bootup
 *
 * Hack to avoid lots of clocksource churn at boot time
 */
static int __init clocksource_done_booting(void)
{
	finished_booting = 1;
	return 0;
}
late_initcall(clocksource_done_booting);
 ...
struct clocksource *clocksource_get_next(void)
{
	unsigned long flags;

	spin_lock_irqsave(&clocksource_lock, flags);
	if (next_clocksource && finished_booting) {
		curr_clocksource = next_clocksource;
		next_clocksource = NULL;
	}
	spin_unlock_irqrestore(&clocksource_lock, flags);

	return curr_clocksource;
}

So even if other clock sources are provided, they'll never show up until
after the radeon driver tries to initialize.

I understand the intention of the clocksource_get_next() code, it doesn't
want to hop onto several different clocksource implementations as the
drivers for those startup, but going through all the module_init() calls
for various drivers without a sane clocksource is just as bad of a problem
and is in fact fatal in this radeon case.
-
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