linux-kernel - [tip:irq/urgent] irqchip/gic-v3-its: Cap lpi_id

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

Date:   Thu, 6 Sep 2018 11:36:52 -0700
From:   tip-bot for Jia He <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     jia.he@...-semitech.com, mingo@...nel.org, marc.zyngier@....com,
        jason@...edaemon.net, tglx@...utronix.de, olof@...om.net,
        linux-kernel@...r.kernel.org, hpa@...or.com
Subject: [tip:irq/urgent] irqchip/gic-v3-its: Cap lpi_id_bits to reduce
 memory footprint

Commit-ID:  4cb205c0c50f613e2de91f0eb19d5247ed003e89
Gitweb:     https://git.kernel.org/tip/4cb205c0c50f613e2de91f0eb19d5247ed003e89
Author:     Jia He <jia.he@...-semitech.com>
AuthorDate: Tue, 28 Aug 2018 12:53:26 +0800
Committer:  Thomas Gleixner <tglx@...utronix.de>
CommitDate: Thu, 6 Sep 2018 20:31:59 +0200

irqchip/gic-v3-its: Cap lpi_id_bits to reduce memory footprint

Commit fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs"), removes
the cap for lpi_id_bits, which causes the following warning to trigger on a
QDF2400 server:

 WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:4066  __alloc_pages_nodemask
 ... 
 Call trace:
  __alloc_pages_nodemask+0x2d8/0x1188
  alloc_pages_current+0x8c/0xd8
  its_allocate_prop_table+0x5c/0xb8
  its_init+0x220/0x3c0
  gic_init_bases+0x250/0x380
  gic_acpi_init+0x16c/0x2a4

In its_alloc_lpi_tables(), lpi_id_bits is 24 in QDF2400. The allocation in
allocate_prop_table() tries therefore to allocate 16M (order 12 if
pagesize=4k), which triggers the warning.

As said by MarcL

 Capping lpi_id_bits at 16 (which is what we had before) is plenty,
 will save a some memory, and gives some margin before we need to push
 it up again.

Bring the upper limit of lpi_id_bits back to prevent

Fixes: fe8e93504ce8 ("irqchip/gic-v3-its: Use full range of LPIs")
Suggested-by: Marc Zyngier <marc.zyngier@....com>
Signed-off-by: Jia He <jia.he@...-semitech.com>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Acked-by: Marc Zyngier <marc.zyngier@....com>
Tested-by: Olof Johansson <olof@...om.net>
Cc: Jason Cooper <jason@...edaemon.net>
Cc: linux-arm-kernel@...ts.infradead.org
Link: https://lkml.kernel.org/r/1535432006-2304-1-git-send-email-jia.he@hxt-semitech.com

---
 drivers/irqchip/irq-gic-v3-its.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 316a57530f6d..c2df341ff6fa 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1439,6 +1439,7 @@ static struct irq_chip its_irq_chip = {
  * The consequence of the above is that allocation is cost is low, but
  * freeing is expensive. We assumes that freeing rarely occurs.
  */
+#define ITS_MAX_LPI_NRBITS	16 /* 64K LPIs */
 
 static DEFINE_MUTEX(lpi_range_lock);
 static LIST_HEAD(lpi_range_list);
@@ -1625,7 +1626,8 @@ static int __init its_alloc_lpi_tables(void)
 {
 	phys_addr_t paddr;
 
-	lpi_id_bits = GICD_TYPER_ID_BITS(gic_rdists->gicd_typer);
+	lpi_id_bits = min_t(u32, GICD_TYPER_ID_BITS(gic_rdists->gicd_typer),
+				ITS_MAX_LPI_NRBITS);
 	gic_rdists->prop_page = its_allocate_prop_table(GFP_NOWAIT);
 	if (!gic_rdists->prop_page) {
 		pr_err("Failed to allocate PROPBASE\n");