linux-kernel - [PATCH 0/2] irqchip/gic-v3-its: a raw_spinlock_t + early ->pend

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

Message-Id: <20180718154205.13704-1-bigeasy@linutronix.de>
Date:   Wed, 18 Jul 2018 17:42:03 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     linux-kernel@...r.kernel.org
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>
Subject: [PATCH 0/2] irqchip/gic-v3-its: a raw_spinlock_t + early ->pend_page allocateion

The errors popped up in -RT. One is the spinlock_t usage in IRQ-off
region which should be a raw_spinlock_t. I don't see this to be used
during run-time or for long period of time so I don't thing this is an
issue.

The second problem is the ->pend_page allocation on the target_cpu early
during CPU bring up. It would be simpler to allocate the memory once on
the boot CPU instead the hotplug callback since the memory is never
free()ed. I *think* this is avoided because the number of possible CPUs
might be higher than what will actually come up (on x86 the BIOS
sometimes reports more possible_cpus than what is *really* possible, not
sure if ARM64 is there yet). Therefore I moved the allocation to an
earlier callback.

Sebastian