Received: by 10.223.185.116 with SMTP id b49csp4181721wrg; Mon, 26 Feb 2018 12:42:18 -0800 (PST) X-Google-Smtp-Source: AH8x225S44Xdr+yqVWYFTYP8sbEpBOO1jtWDt5X7T2GaHuHBFhM7V0+Lb66obuxqQBlrefYPo/4X X-Received: by 2002:a17:902:128c:: with SMTP id g12-v6mr11824654pla.85.1519677738257; Mon, 26 Feb 2018 12:42:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519677738; cv=none; d=google.com; s=arc-20160816; b=bq7WpQpKx81t1vaEjI3KPbkX6LwMFaGpgSm84pZoATanm6XzInwt7Dho/5MfeToI/h iaBQUeiqWjVz+PJ1T3olMMIpsm38s0vPaNPq6FnkTAkH/ebYiiynsLarqDR1L9eRycoJ umiSSKBmsA0Q5VQ7aJiryKZTB9bVqWDp86hRTHFGkeqIt9jY5gT8CTNAaXsJoYWTxUuV QmtMEr4qxFIw/q84rQk7JuxBM1ytlAl6xUi0wYlpQV5AKPjeXFrgl0RUm5c16EYe06Qr ZNvnTNlUslzm1oBhQDxglXfyjOWkAi+tXl3Oz6zjCFHb75YxGqf/pXM7nFcX2lh1BpF0 JY1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=dO4mQlhlrChXh2ZkZrW+l0q4sGlSkK17/gAv5KA+shQ=; b=AZjvluz4t6vjy7gl9iNz7sRcg7D/qec1zioW/MSPSvyU+5CxuqWCLIjAxUwxfvZ98d YLhdxKovvOui6O89OOfstw8tBbzjtryUsP/Ny7nI/CjdI2IDfGF3Tve6We7n/E9HS2FN SHaMT+wuHoQnd43OSb2kGkw1y8rU58vd/qaqYHVOkFrvx3QkwE/U+wn2/bgsXPD8Huj4 JsSkEXJSzdgzju4yiO3J0WNg5dOuoQiUU8pIAYngdbKncGU4ZPmb3YzHJngkvOkFWXEQ 4Hupi8+xLqmr9QmhfsYNtyEutxuE07fWm0dbCZ5tVrDhg346faSqQhrBx2oEuONMREMP pDOw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t74si5937328pgc.649.2018.02.26.12.42.01; Mon, 26 Feb 2018 12:42:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753618AbeBZU1I (ORCPT + 99 others); Mon, 26 Feb 2018 15:27:08 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:36342 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753600AbeBZU1F (ORCPT ); Mon, 26 Feb 2018 15:27:05 -0500 Received: from localhost (clnet-b04-243.ikbnet.co.at [83.175.124.243]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 35CC9E30; Mon, 26 Feb 2018 20:27:04 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yuriy Vostrikov , Thomas Gleixner , Peter Zijlstra , Randy Dunlap , Ingo Molnar Subject: [PATCH 4.15 27/64] x86/apic/vector: Handle vector release on CPU unplug correctly Date: Mon, 26 Feb 2018 21:22:04 +0100 Message-Id: <20180226202154.620009713@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180226202153.453363333@linuxfoundation.org> References: <20180226202153.453363333@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Gleixner commit e84cf6aa501c58bf4bf451f1e425192ec090aed2 upstream. When a irq vector is replaced, then the previous vector is normally released when the first interrupt happens on the new vector. If the target CPU of the previous vector is already offline when the new vector is installed, then the previous vector is silently discarded, which leads to accounting issues causing suspend failures and other problems. Adjust the logic so that the previous vector is freed in the underlying matrix allocator to ensure that the accounting stays correct. Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment") Reported-by: Yuriy Vostrikov Signed-off-by: Thomas Gleixner Tested-by: Yuriy Vostrikov Cc: Peter Zijlstra Cc: Randy Dunlap Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180222112316.930791749@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/apic/vector.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -134,21 +134,40 @@ static void apic_update_vector(struct ir { struct apic_chip_data *apicd = apic_chip_data(irqd); struct irq_desc *desc = irq_data_to_desc(irqd); + bool managed = irqd_affinity_is_managed(irqd); lockdep_assert_held(&vector_lock); trace_vector_update(irqd->irq, newvec, newcpu, apicd->vector, apicd->cpu); - /* Setup the vector move, if required */ - if (apicd->vector && cpu_online(apicd->cpu)) { + /* + * If there is no vector associated or if the associated vector is + * the shutdown vector, which is associated to make PCI/MSI + * shutdown mode work, then there is nothing to release. Clear out + * prev_vector for this and the offlined target case. + */ + apicd->prev_vector = 0; + if (!apicd->vector || apicd->vector == MANAGED_IRQ_SHUTDOWN_VECTOR) + goto setnew; + /* + * If the target CPU of the previous vector is online, then mark + * the vector as move in progress and store it for cleanup when the + * first interrupt on the new vector arrives. If the target CPU is + * offline then the regular release mechanism via the cleanup + * vector is not possible and the vector can be immediately freed + * in the underlying matrix allocator. + */ + if (cpu_online(apicd->cpu)) { apicd->move_in_progress = true; apicd->prev_vector = apicd->vector; apicd->prev_cpu = apicd->cpu; } else { - apicd->prev_vector = 0; + irq_matrix_free(vector_matrix, apicd->cpu, apicd->vector, + managed); } +setnew: apicd->vector = newvec; apicd->cpu = newcpu; BUG_ON(!IS_ERR_OR_NULL(per_cpu(vector_irq, newcpu)[newvec]));