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:	Sun, 22 Feb 2015 23:13:58 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Michael Ellerman <mpe@...erman.id.au>, Paul Clarke <pc@...ibm.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] powerpc: re-enable dynticks

Hi Ben,

2015-02-16 5:06 GMT+01:00 Benjamin Herrenschmidt <benh@...nel.crashing.org>:
> On Mon, 2015-02-16 at 11:08 +1100, Michael Ellerman wrote:
>> On Fri, 2015-02-13 at 13:38 -0600, Paul Clarke wrote:
>> > implement arch_irq_work_has_interrupt() for powerpc
>> >
>> > Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for
>> > full dynamic ticks to be enabled, by expecting architectures to
>> > implement a suitable arch_irq_work_has_interrupt() routine.
>> >
>> > Several arches have implemented this routine, including x86 (3010279f)
>> > and arm (09f6edd4), but powerpc was omitted.
>> >
>> > This patch implements this routine for powerpc.
>> >
>  .../...
>>
>> It makes the message change, but is that correct? ie. do we actually implement
>> "IRQ work self-IPIs"?
>
> I think so... Fred, do you think what we do will work ? We hijack our
> decrementer (local timer) by making it shoot almost immediately (1 tick
> away) and run the irq work at the beginning of __timer_interrupt().
>
> At that point we are on our irq stack and have done irq_enter but that's
> about it.

Yes that should work. After all "self-IPI" is an oxymoron. One would
expect an IPI to be triggered by an irq controller but if such
operation isn't supported with the current CPU being both source and
destination, anything triggering the desired callback in an interrupt
context in a reasonable amount of time ahead does the job here.

I thought well that's what powerpc was doing for irq work but I wasn't
sure I understood the code correctly. I should have pinged people
about that, sorry.

Thanks.

>
> Cheers,
> Ben.
>
>> > diff --git a/arch/powerpc/include/asm/irq_work.h
>> > b/arch/powerpc/include/asm/irq_work.h
>> > new file mode 100644
>> > index 0000000..18365ec
>> > --- /dev/null
>> > +++ b/arch/powerpc/include/asm/irq_work.h
>> > @@ -0,0 +1,11 @@
>> > +#ifndef _ASM_IRQ_WORK_H
>> > +#define _ASM_IRQ_WORK_H
>> > +
>> > +#include <asm/processor.h>
>> > +
>> > +static inline bool arch_irq_work_has_interrupt(void)
>> > +{
>> > +   return 1;
>>
>> Should be "true";
>>
>> > +}
>>
>> cheers
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@...ts.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
--
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