linux-kernel - Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

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:	Tue, 06 Mar 2007 16:53:36 -0800
From:	Dan Hecht <dhecht@...are.com>
To:	tglx@...utronix.de
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Zachary Amsden <zach@...are.com>, Ingo Molnar <mingo@...e.hu>,
	akpm@...ux-foundation.org, ak@...e.de,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	LKML <linux-kernel@...r.kernel.org>,
	john stultz <johnstul@...ibm.com>,
	Dan Hecht <dhecht@...are.com>
Subject: Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

On 03/06/2007 04:49 PM, Thomas Gleixner wrote:
> On Tue, 2007-03-06 at 16:35 -0800, Dan Hecht wrote:
>>>> There is no problem for realtime uses, as the reprogramming path is
>>>> running with local interrupts disabled. I can see the point for paravirt
>>>> and I'm not opposed to change / expand the interface for that. It might
>>>> be done by an extra clockevents feature flag, which requests absolute
>>>> time instead of relative time.
>>>>   
>>> I'm not sure how much different it makes overall.  It's true that
>>> absolute time would be a more useful interface, but because the guest
>>> vcpu can be preempted at any time, we could miss the timeout
>>> regardless.  In Xen if you set a timeout for the past you get an
>>> immediate interrupt; I presume the clockevent code can deal with that?
>>>
>> That's the problem though, you won't know to set it for the past since 
>> the expiry is relative.  When the vcpu starts running again, it will set 
>> the timer to expire X ns from now, not Xns from when the timer was 
>> requested.
> 
> Ooops. I completely forgot, that you get the absolute expiry time
> already in ktime_t format (nanoseconds) when dev->set_next_event() is
> called.
> 
> 	dev->next_event = expires;
> 
> is done right before the call. 
> 
> So it's already there for free.
> 
>

Okay.  I noticed that but didn't think it was okay to use since it 
didn't seem like it was set up for the clock_event_device code's use, so 
seemed like a conceptual interface violation to go digging around in 
there.

Also, wasn't one of the points of clockevents to prevent the device code 
from doing conversions between nanoseconds and clicks themselves?  Don't 
we really want the clockevents generic layer to do this conversion 
between monotonic nanonseconds to absolute device clicks and then give 
the device code that value, so the device layer doesn't perform any 
conversions?


On an unrelated note, can you explain what the difference between 
CLOCK_EVT_MODE_UNUSED and CLOCK_EVT_MODE_SHUTDOWN modes are and what the 
legal state transitions are? (or point me to a document describing 
this).  At least on i386, all clock event devices treat them the same; 
do we really need both?

-
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/