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] [day] [month] [year] [list]
Date:	Mon, 11 Jan 2010 13:38:17 +1000
From:	Greg Ungerer <gerg@...pgear.com>
To:	john stultz <johnstul@...ibm.com>
CC:	Steven King <sfking@...dc.com>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.33-rc1: hrtimers and tickless broken on m68knommu.

Hi John,

Sorry for no response on this, I have been away.


john stultz wrote:
> On Fri, 2009-12-18 at 19:20 -0800, Steven King wrote:
>> On Friday 18 December 2009 06:44:44 john stultz wrote:
>>> On Fri, Dec 18, 2009 at 6:13 PM, Steven King <sfking@...dc.com> wrote:
>>>> Attach is the .config; it works on v2.6.32 but fails to boot on .33-rc1;
>>>> but if I deselect hrtimers && tickless then it works.
>>> Sorry for the dup, forgot to cc lkml on my reply.
>>>
>>> Fails to boot all together? Or does it hang at some point in the dmesg
>>> that you can point out?
>> fails to boot all together; nothing on the serial console.
>>> Could you run the following so we can narrow down which clocksource your
>>> using? cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>>> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>>>
>>> Then with the kernel that doesn't boot, go through the clocksources
>>> listed in available_clocksources and try booting w/
>>> "clocksource=<clock name>" and see if the behavior changes.
>> on the working .32 kernel:
>>
>> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> pit
>> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>> pit
>>
>> just to be sure, I tried clocksource=pit on the .33-rc1 kernel.  It didnt make 
>> any difference.
> 
> 
> Hrmm.. So looking at the code in arch/m68knommu/platform/coldfire/pit.c,
> I'm a little confused on how this got marked as a continuous clocksource
> (CLOCK_SOURCE_IS_CONTINUOUS), especially as it seems it couldn't handle
> skipping an interrupt.
> 
> That said, I'm not sure how it worked in 2.6.32, as its been that way
> for awhile it seems.  Maybe my assumptions on how the PIT works is wrong
> (or just biased in how it works on x86)?
> 
> Greg, could you clarify how the PIT can be used as a clocksource if its
> also being used in oneshot mode?

Looks broken. As Steven noted we just seem to have gotten away
with it, with no obvious breakage so far.

I see from follow-ons to this that Andrew has picked it up.
So I'll just ack that and let him push it.

Thanks
Greg


> Steven, I assume the patch below avoids the issue (by disabling highres
> timers and nohz)?
> 
> thanks
> -john
> 
> 
> 
> The m68knommu coldfire pit clocksource looks like it was incorrectly
> marked as a continuous clocksource. From the looks of it, running with
> it marked as a continuous clocksource could cause hangs when the system
> switches to highres mode or enables nohz.  I have no idea why it worked
> in prior kernels, and I'm not 100% sure the following fix is really the
> right solution.
> 
> This patch removes the CLOCK_SOURCE_IS_CONTINUOUS flag on the coldfire
> pit clocksource. This will disallow systems using this clocksource from
> entering oneshot mode (disabling highres timers and nohz).
> 
> Signed-off-by: John Stultz <johnstul@...ibm.com>
> 
> ---
> 
> diff --git a/arch/m68knommu/platform/coldfire/pit.c b/arch/m68knommu/platform/coldfire/pit.c
> index d8720ee..aebea19 100644
> --- a/arch/m68knommu/platform/coldfire/pit.c
> +++ b/arch/m68knommu/platform/coldfire/pit.c
> @@ -146,7 +146,6 @@ static struct clocksource pit_clk = {
>  	.read	= pit_read_clk,
>  	.shift	= 20,
>  	.mask	= CLOCKSOURCE_MASK(32),
> -	.flags	= CLOCK_SOURCE_IS_CONTINUOUS,
>  };
>  
>  /***************************************************************************/
> 
> 
> 


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@...pgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
--
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