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: <1397663995.19782.4.camel@AMDC1943>
Date:	Wed, 16 Apr 2014 17:59:55 +0200
From:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	linux-arm-kernel@...ts.infradead.org, stable@...r.kernel.org
Subject: Re: [patch 0/4] genirq/exynos timers: Fix the CPU hotplug wreckage
 sanely

On śro, 2014-04-16 at 14:36 +0000, Thomas Gleixner wrote:
> The current implementation of irq_set_affinity() refuses rightfully to
> route an interrupt to an offline cpu.
> 
> But there is a special case, where this is actually desired. Some of
> the ARM SoCs have per cpu timers which require setting the affinity
> during cpu startup where the cpu is not yet in the online mask.
> 
> If we can't do that, then the local timer interrupt for the about to
> become online cpu is routed to some random online cpu.
> 
> The developers of the affected machines tried to work around that
> issue, but that results in a massive mess in that timer code.
> 
> It's saner to provide a facility to force the affinity and make the
> affected machines use that.
> 
> The following series implements that logic w/o impact on any existing
> users.
> 
> The change to the genirq core code is not that bad:
> 
>  arch/mips/cavium-octeon/octeon-irq.c |    2 +-
>  include/linux/interrupt.h            |   35 ++++++++++++++++++++++++++++++++++-
>  include/linux/irq.h                  |    3 ++-
>  kernel/irq/manage.c                  |   17 ++++++-----------
>  4 files changed, 43 insertions(+), 14 deletions(-)
> 
> The resulting fixup for gic/exynos_mct is:
> 
>  clocksource/exynos_mct.c |   12 +++---------
>  irqchip/irq-gic.c        |    8 ++++++--
>  2 files changed, 9 insertions(+), 11 deletions(-)
> 
> Krzysztofs proposed workaround was slightly smaller than that, but I
> prefer having a clean solution for backporting to stable rather than a
> messy hack around which works.
> 
> @Krzysztof: Can you please retest the series? I've changed the core
> implementation versus the first attempt to make it less intrusive.

Works fine. Tested whole patchset on board with Exynos 3250.

Best regards,
Krzysztof


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