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]
Message-Id: <1179302432.12838.62.camel@chaos>
Date:	Wed, 16 May 2007 10:00:32 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Francis Moreau <francis.moro@...il.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: clockevent questions

On Wed, 2007-05-16 at 09:42 +0200, Francis Moreau wrote:
> > On Tue, 2007-05-15 at 10:47 +0200, Francis Moreau wrote:
> > > My question is about the clock resolution field which is equal to 1ns.
> > > How is this possible since my timer's frequency is only 100Mhz ?
> >
> > you are right. It is a bit strange. The resolution info is not really
> > reflecting the clock event source capability. I look if there is a sane
> > solution for that.
> >
> 
> Doesn't that make hrtimer_get_res() and its callers buggy since they
> return this 1ns value which is not reflecting the correct clock event
> capability ?

Well, it's not really buggy. It's just not telling the truth.

> Another question about the output of '/proc/timer_list':
> 
> [...]
> active timers:
>  #0: <c03fde10>, tick_sched_timer, S:01
>  # expires at 64696546875000 nsecs [in 2514469 nsecs]
>  .expires_next   : 64696546875000 nsecs
> [...]
> 
> Doesn't the 2 expire time lines give the same information ? If so,
> couldn't we merge them into : ".expires_next   : 64696546875000 nsecs
> [in 2514469 nsecs]" ?

No. The timers are taken from the hrtimer queue and the expires_next
value is the clock events code internal value of the next timer event.
The expiry time of the first timer and the clock events code should
match of course, but we definitely want to have them seperate.

	tglx


-
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