Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp825799imm; Wed, 6 Jun 2018 06:36:16 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIbF5roiroLQthbq1NAwDgGUlF32PWjodlTrwFqoVO3tcLQf/VwYBfNLO3oNx8NIF/k6zHI X-Received: by 2002:a62:ea14:: with SMTP id t20-v6mr2030564pfh.117.1528292176455; Wed, 06 Jun 2018 06:36:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528292176; cv=none; d=google.com; s=arc-20160816; b=T2aJ0AbbDueWG1eqf6JM2sM8wvX+a8C5tJouQ78m1c8AT5k/uhIF3qog030svxQQE5 f6Dn6JoZOs1GJmglqaeFzazt3w34r3yRl8NgRWQUr2Z64tXCHXuoi/+u1njYbCQsHF81 9YhgQASLQCr5UGlz37SgZmbE8MCiajkIfDWQVbEpLI1FHgSbbS4orGMz+CteRWEogFXY 3DUGI0v8uMafzuU2nDl8W3iYct26OvpPbTTqRS5nDOJ4f/fmVnOFQz2tZcywzYJ8buE5 JHt2T0wRlreH6nWilyGAsEQDXF5NIdmt+OHzC0GjhvCeG0UEzBX6SWorZdWVUONzHxnv 2SIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:mime-version:robot-unsubscribe:robot-id :git-commit-id:subject:to:references:in-reply-to:reply-to:cc :message-id:from:date:arc-authentication-results; bh=OgcWoXiKVIqEOrnG86cpIZkG9sn0anlsPS4KOr+zy+k=; b=F1bbkpoavruvi6oAq9YfYZQAeB37eL1iJpb8SANP5gX9/Ie5Yf6Er9V59DEjIpsv3P 4J0BJUe6WBQiTSmw6gGaGVGw9YlgeZN77Q2jfVLK3BCW8o+r5r5gtrMZ56+/14oESird d80fYvDZGceLIfWr3d85WfJ0ebSYnbBil6HZzwDa7XH5qjt0IUVI1jKS29VQgHtnkHI/ Wsu1qKsNYswuFOv0WEYz0X3Fsdy9eHS3OZPdU0NAriu0bbyPb4lZh5ppBPA60SyrymDb JaeadG2SCVm4yYWUV/1DoRTR6w8JGf0B2HSAsQNceK6DmRzNaZqmkbpa0KSRIv20fGQX 9+yg== 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 v18-v6si327978pff.248.2018.06.06.06.36.02; Wed, 06 Jun 2018 06:36:16 -0700 (PDT) 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 S1752422AbeFFNdV (ORCPT + 99 others); Wed, 6 Jun 2018 09:33:21 -0400 Received: from terminus.zytor.com ([198.137.202.136]:52999 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751870AbeFFNcA (ORCPT ); Wed, 6 Jun 2018 09:32:00 -0400 Received: from terminus.zytor.com (localhost [127.0.0.1]) by terminus.zytor.com (8.15.2/8.15.2) with ESMTPS id w56DVPJu1794037 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jun 2018 06:31:25 -0700 Received: (from tipbot@localhost) by terminus.zytor.com (8.15.2/8.15.2/Submit) id w56DVP571794034; Wed, 6 Jun 2018 06:31:25 -0700 Date: Wed, 6 Jun 2018 06:31:25 -0700 X-Authentication-Warning: terminus.zytor.com: tipbot set sender to tipbot@zytor.com using -f From: tip-bot for Thomas Gleixner Message-ID: Cc: tariqt@mellanox.com, bp@alien8.de, mingo@kernel.org, liu.song.a23@gmail.com, jroedel@suse.de, tglx@linutronix.de, linux-kernel@vger.kernel.org, songliubraving@fb.com, 0x7f454c46@gmail.com, mike.travis@hpe.com, hpa@zytor.com, peterz@infradead.org Reply-To: mingo@kernel.org, jroedel@suse.de, liu.song.a23@gmail.com, bp@alien8.de, tariqt@mellanox.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, 0x7f454c46@gmail.com, songliubraving@fb.com, peterz@infradead.org, hpa@zytor.com, mike.travis@hpe.com In-Reply-To: <20180604162224.386544292@linutronix.de> References: <20180604162224.386544292@linutronix.de> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/urgent] genirq/generic_pending: Do not lose pending affinity update Git-Commit-ID: a33a5d2d16cb84bea8d5f5510f3a41aa48b5c467 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline X-Spam-Status: No, score=-0.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on terminus.zytor.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: a33a5d2d16cb84bea8d5f5510f3a41aa48b5c467 Gitweb: https://git.kernel.org/tip/a33a5d2d16cb84bea8d5f5510f3a41aa48b5c467 Author: Thomas Gleixner AuthorDate: Mon, 4 Jun 2018 17:33:54 +0200 Committer: Thomas Gleixner CommitDate: Wed, 6 Jun 2018 15:18:19 +0200 genirq/generic_pending: Do not lose pending affinity update The generic pending interrupt mechanism moves interrupts from the interrupt handler on the original target CPU to the new destination CPU. This is required for x86 and ia64 due to the way the interrupt delivery and acknowledge works if the interrupts are not remapped. However that update can fail for various reasons. Some of them are valid reasons to discard the pending update, but the case, when the previous move has not been fully cleaned up is not a legit reason to fail. Check the return value of irq_do_set_affinity() for -EBUSY, which indicates a pending cleanup, and rearm the pending move in the irq dexcriptor so it's tried again when the next interrupt arrives. Fixes: 996c591227d9 ("x86/irq: Plug vector cleanup race") Signed-off-by: Thomas Gleixner Tested-by: Song Liu Cc: Joerg Roedel Cc: Peter Zijlstra Cc: Song Liu Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: stable@vger.kernel.org Cc: Mike Travis Cc: Borislav Petkov Cc: Tariq Toukan Link: https://lkml.kernel.org/r/20180604162224.386544292@linutronix.de --- kernel/irq/migration.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/kernel/irq/migration.c b/kernel/irq/migration.c index 86ae0eb80b53..8b8cecd18cce 100644 --- a/kernel/irq/migration.c +++ b/kernel/irq/migration.c @@ -38,17 +38,18 @@ bool irq_fixup_move_pending(struct irq_desc *desc, bool force_clear) void irq_move_masked_irq(struct irq_data *idata) { struct irq_desc *desc = irq_data_to_desc(idata); - struct irq_chip *chip = desc->irq_data.chip; + struct irq_data *data = &desc->irq_data; + struct irq_chip *chip = data->chip; - if (likely(!irqd_is_setaffinity_pending(&desc->irq_data))) + if (likely(!irqd_is_setaffinity_pending(data))) return; - irqd_clr_move_pending(&desc->irq_data); + irqd_clr_move_pending(data); /* * Paranoia: cpu-local interrupts shouldn't be calling in here anyway. */ - if (irqd_is_per_cpu(&desc->irq_data)) { + if (irqd_is_per_cpu(data)) { WARN_ON(1); return; } @@ -73,9 +74,20 @@ void irq_move_masked_irq(struct irq_data *idata) * For correct operation this depends on the caller * masking the irqs. */ - if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) - irq_do_set_affinity(&desc->irq_data, desc->pending_mask, false); - + if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) { + int ret; + + ret = irq_do_set_affinity(data, desc->pending_mask, false); + /* + * If the there is a cleanup pending in the underlying + * vector management, reschedule the move for the next + * interrupt. Leave desc->pending_mask intact. + */ + if (ret == -EBUSY) { + irqd_set_move_pending(data); + return; + } + } cpumask_clear(desc->pending_mask); }