linux-kernel - Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

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]

Message-ID: <21606.1157718592@warthog.cambridge.redhat.com>
Date:	Fri, 08 Sep 2006 13:29:52 +0100
From:	David Howells <dhowells@...hat.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	David Howells <dhowells@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	john stultz <johnstul@...ibm.com>,
	Adrian Bunk <bunk@...sta.de>, Andrew Morton <akpm@...l.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Jeff Garzik <jeff@...zik.org>,
	netdev@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj 

Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:

> > > Now, if you have funky cascades, then you can always group them into a
> > > virtual irq cascade line and have a special chained flow handler that
> > > does all the "figuring out" off those... it's up to you. 
> > 
> > You make it sound so easy, but it's not obvious how to do this, apart from
> > installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
> > having those call back into __do_IRQ().  Chaining isn't mentioned in
> > genericirq.tmpl.
> 
> No, you do a chain handler. Look at how I do it in
> arch/powerpc/platform/pseries/setup.c for example. It's actually
> trivial. You install a special flow handler (which means that there is
> very little overhead, almost none, from the toplevel irq to the chained
> irq). You can _also_ if you want just install an IRQ handler for the
> cascaded controller and call generic_handle_irq (rather than __do_IRQ)
> from it, but that has more overhead. A chained handler completely
> relaces the flow handler for the cascade, and thus, if you don't need
> all of the nits and bits of the other flow handlers for your cascade,
> you can speed things up by hooking at that level.

But funky cascading using chained flow handlers doesn't work if the cascade
must share an IRQ with some other device, right?

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