linux-kernel - Moving GPIO interrupts and IPIs to a core other than 0

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>] [day] [month] [year] [list]

Message-Id: <DE69CD9B-B15D-41DF-8CAF-57D246296074@gmail.com>
Date:   Sun, 21 Aug 2016 21:11:42 -0500
From:   "T. Smith" <tlsmith3777@...il.com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "irqbalance@...ts.infradead.org" <irqbalance@...ts.infradead.org>
Subject: Moving GPIO interrupts and IPIs to a core other than 0

On the 4.1.8-rt8+gdb51baf SMP PREMPT RT kernel, GPIO interrupts are assigned to core 0 as are the following IPI interrupts:

Arch_timer
Rescheduling Interrupt
Function call interrupt

Trying to assign GPIO interrupts to core 2 for example, or trying to reassign or move IPI interrupts running on core 0 to some other core does not seem possible since attempting to move these was unsuccessful. Successfully moved other ISRs and tasks to other cores with no problem.

1.  How does one control GPIO ISR affinity when GPIOs interrupts always appear to run on Core 0? How do we assign GPIO interrupts to any core other than Core#0. 

2.  It looks like the existing GPIO driver does not support assigning interrupts to any other core than CPU0, is this correct?

3.  If so, why are GPIO interrupts assigned only to Core#0?

4.  There are virtual GPIO interrupts and GPIO hardware interrupts, can either or both interrupts be assigned to a specific core other than Core#0?

5.  Is it possible to isolate a given CPU core from the following IPI interrupts, and if so, how do we isolate CPU0 from the following IPI interrupts.  If not, why are these always serviced on boot core 0? Arch_timer, Rescheduling Interrupt, Function call interrupt

Creating the GPIO interrupt:

root:~# echo 498 > /sys/class/gpio/export
root:~# echo falling > /sys/class/gpio/gpio498/edge
root:~# cat /proc/interrupts

              CPU0         CPU1       CPU2       CPU3
[....]         
66:            0            0          0          0     GIC 106
Level        1740000.jr
67:            0            0          0          0     mpc8xxx-gpio   18
Edge         gpiolib
IPI0:          3226         4833       4237      4170   Recheduling interrupts
IPI1:            17           21         19        23   Function call interrupts

Setting GPIO affinity doesn’t work:

root:~# echo 1 > /proc/irq/67/smp_affinity_list-sh: echo: write error: Input/output error

Setting eMMC interrupt affinity works just fine:

root:~# echo 1 > /proc/irq/12/smp_affinity_list
root:~# cat /proc/interrupts

CPU0         CPU1       CPU2       CPU3
[....]         
1:            0            0          0          0     GIC 29
Edge        arch_timer
2:           35475          39336    28975       38803 GIC 30
Edge        arch_timer
11             9           0          0           0    GIC 75 Level    fsl-ifc
12:           3370         14         0           0    GIC 94 Level    mmc0
[...]

thx, Tracy