--- /dev/null
+From f0c7baca180046824e07fc5f1326e83a8fd150c7 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Fri, 24 Jul 2020 22:44:41 +0200
+Subject: genirq/affinity: Make affinity setting if activated opt-in
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit f0c7baca180046824e07fc5f1326e83a8fd150c7 upstream.
+
+John reported that on a RK3288 system the perf per CPU interrupts are all
+affine to CPU0 and provided the analysis:
+
+ "It looks like what happens is that because the interrupts are not per-CPU
+ in the hardware, armpmu_request_irq() calls irq_force_affinity() while
+ the interrupt is deactivated and then request_irq() with IRQF_PERCPU |
+ IRQF_NOBALANCING.
+
+ Now when irq_startup() runs with IRQ_STARTUP_NORMAL, it calls
+ irq_setup_affinity() which returns early because IRQF_PERCPU and
+ IRQF_NOBALANCING are set, leaving the interrupt on its original CPU."
+
+This was broken by the recent commit which blocked interrupt affinity
+setting in hardware before activation of the interrupt. While this works in
+general, it does not work for this particular case. As contrary to the
+initial analysis not all interrupt chip drivers implement an activate
+callback, the safe cure is to make the deferred interrupt affinity setting
+at activation time opt-in.
+
+Implement the necessary core logic and make the two irqchip implementations
+for which this is required opt-in. In hindsight this would have been the
+right thing to do, but ...
+
+Fixes: baedb87d1b53 ("genirq/affinity: Handle affinity setting on inactive interrupts correctly")
+Reported-by: John Keeping <john@metanate.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Marc Zyngier <maz@kernel.org>
+Acked-by: Marc Zyngier <maz@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/87blk4tzgm.fsf@nanos.tec.linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/apic/vector.c | 4 ++++
+ drivers/irqchip/irq-gic-v3-its.c | 5 ++++-
+ include/linux/irq.h | 13 +++++++++++++
+ kernel/irq/manage.c | 6 +++++-
+ 4 files changed, 26 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/apic/vector.c
++++ b/arch/x86/kernel/apic/vector.c
+@@ -560,6 +560,10 @@ static int x86_vector_alloc_irqs(struct
+ * as that can corrupt the affinity move state.
+ */
+ irqd_set_handle_enforce_irqctx(irqd);
++
++ /* Don't invoke affinity setter on deactivated interrupts */
++ irqd_set_affinity_on_activate(irqd);
++
+ /*
+ * Legacy vectors are already assigned when the IOAPIC
+ * takes them over. They stay on the same vector. This is
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -3399,6 +3399,7 @@ static int its_irq_domain_alloc(struct i
+ msi_alloc_info_t *info = args;
+ struct its_device *its_dev = info->scratchpad[0].ptr;
+ struct its_node *its = its_dev->its;
++ struct irq_data *irqd;
+ irq_hw_number_t hwirq;
+ int err;
+ int i;
+@@ -3418,7 +3419,9 @@ static int its_irq_domain_alloc(struct i
+
+ irq_domain_set_hwirq_and_chip(domain, virq + i,
+ hwirq + i, &its_irq_chip, its_dev);
+- irqd_set_single_target(irq_desc_get_irq_data(irq_to_desc(virq + i)));
++ irqd = irq_get_irq_data(virq + i);
++ irqd_set_single_target(irqd);
++ irqd_set_affinity_on_activate(irqd);
+ pr_debug("ID:%d pID:%d vID:%d\n",
+ (int)(hwirq + i - its_dev->event_map.lpi_base),
+ (int)(hwirq + i), virq + i);
+--- a/include/linux/irq.h
++++ b/include/linux/irq.h
+@@ -213,6 +213,8 @@ struct irq_data {
+ * required
+ * IRQD_HANDLE_ENFORCE_IRQCTX - Enforce that handle_irq_*() is only invoked
+ * from actual interrupt context.
++ * IRQD_AFFINITY_ON_ACTIVATE - Affinity is set on activation. Don't call
++ * irq_chip::irq_set_affinity() when deactivated.
+ */
+ enum {
+ IRQD_TRIGGER_MASK = 0xf,
+@@ -237,6 +239,7 @@ enum {
+ IRQD_CAN_RESERVE = (1 << 26),
+ IRQD_MSI_NOMASK_QUIRK = (1 << 27),
+ IRQD_HANDLE_ENFORCE_IRQCTX = (1 << 28),
++ IRQD_AFFINITY_ON_ACTIVATE = (1 << 29),
+ };
+
+ #define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
+@@ -421,6 +424,16 @@ static inline bool irqd_msi_nomask_quirk
+ return __irqd_to_state(d) & IRQD_MSI_NOMASK_QUIRK;
+ }
+
++static inline void irqd_set_affinity_on_activate(struct irq_data *d)
++{
++ __irqd_to_state(d) |= IRQD_AFFINITY_ON_ACTIVATE;
++}
++
++static inline bool irqd_affinity_on_activate(struct irq_data *d)
++{
++ return __irqd_to_state(d) & IRQD_AFFINITY_ON_ACTIVATE;
++}
++
+ #undef __irqd_to_state
+
+ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
+--- a/kernel/irq/manage.c
++++ b/kernel/irq/manage.c
+@@ -320,12 +320,16 @@ static bool irq_set_affinity_deactivated
+ struct irq_desc *desc = irq_data_to_desc(data);
+
+ /*
++ * Handle irq chips which can handle affinity only in activated
++ * state correctly
++ *
+ * If the interrupt is not yet activated, just store the affinity
+ * mask and do not call the chip driver at all. On activation the
+ * driver has to make sure anyway that the interrupt is in a
+ * useable state so startup works.
+ */
+- if (!IS_ENABLED(CONFIG_IRQ_DOMAIN_HIERARCHY) || irqd_is_activated(data))
++ if (!IS_ENABLED(CONFIG_IRQ_DOMAIN_HIERARCHY) ||
++ irqd_is_activated(data) || !irqd_affinity_on_activate(data))
+ return false;
+
+ cpumask_copy(desc->irq_common_data.affinity, mask);
--- /dev/null
+From e27b1636e9337d1a1d174b191e53d0f86421a822 Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Tue, 11 Aug 2020 11:00:01 -0700
+Subject: genirq/PM: Always unlock IRQ descriptor in rearm_wake_irq()
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit e27b1636e9337d1a1d174b191e53d0f86421a822 upstream.
+
+rearm_wake_irq() does not unlock the irq descriptor if the interrupt
+is not suspended or if wakeup is not enabled on it.
+
+Restucture the exit conditions so the unlock is always ensured.
+
+Fixes: 3a79bc63d9075 ("PCI: irq: Introduce rearm_wake_irq()")
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200811180001.80203-1-linux@roeck-us.net
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/irq/pm.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/kernel/irq/pm.c
++++ b/kernel/irq/pm.c
+@@ -185,14 +185,18 @@ void rearm_wake_irq(unsigned int irq)
+ unsigned long flags;
+ struct irq_desc *desc = irq_get_desc_buslock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
+
+- if (!desc || !(desc->istate & IRQS_SUSPENDED) ||
+- !irqd_is_wakeup_set(&desc->irq_data))
++ if (!desc)
+ return;
+
++ if (!(desc->istate & IRQS_SUSPENDED) ||
++ !irqd_is_wakeup_set(&desc->irq_data))
++ goto unlock;
++
+ desc->istate &= ~IRQS_SUSPENDED;
+ irqd_set(&desc->irq_data, IRQD_WAKEUP_ARMED);
+ __enable_irq(desc);
+
++unlock:
+ irq_put_desc_busunlock(desc, flags);
+ }
+
--- /dev/null
+From dae68d7fd4930315389117e9da35b763f12238f9 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Fri, 26 Jun 2020 19:42:34 +0200
+Subject: PCI: hotplug: ACPI: Fix context refcounting in acpiphp_grab_context()
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit dae68d7fd4930315389117e9da35b763f12238f9 upstream.
+
+If context is not NULL in acpiphp_grab_context(), but the
+is_going_away flag is set for the device's parent, the reference
+counter of the context needs to be decremented before returning
+NULL or the context will never be freed, so make that happen.
+
+Fixes: edf5bf34d408 ("ACPI / dock: Use callback pointers from devices' ACPI hotplug contexts")
+Reported-by: Vasily Averin <vvs@virtuozzo.com>
+Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/hotplug/acpiphp_glue.c | 14 +++++++++++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+--- a/drivers/pci/hotplug/acpiphp_glue.c
++++ b/drivers/pci/hotplug/acpiphp_glue.c
+@@ -122,13 +122,21 @@ static struct acpiphp_context *acpiphp_g
+ struct acpiphp_context *context;
+
+ acpi_lock_hp_context();
++
+ context = acpiphp_get_context(adev);
+- if (!context || context->func.parent->is_going_away) {
+- acpi_unlock_hp_context();
+- return NULL;
++ if (!context)
++ goto unlock;
++
++ if (context->func.parent->is_going_away) {
++ acpiphp_put_context(context);
++ context = NULL;
++ goto unlock;
+ }
++
+ get_bridge(context->func.parent);
+ acpiphp_put_context(context);
++
++unlock:
+ acpi_unlock_hp_context();
+ return context;
+ }
--- /dev/null
+From 0a018944eee913962bce8ffebbb121960d5125d9 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Thu, 16 Jul 2020 00:34:21 -0500
+Subject: smb3: warn on confusing error scenario with sec=krb5
+
+From: Steve French <stfrench@microsoft.com>
+
+commit 0a018944eee913962bce8ffebbb121960d5125d9 upstream.
+
+When mounting with Kerberos, users have been confused about the
+default error returned in scenarios in which either keyutils is
+not installed or the user did not properly acquire a krb5 ticket.
+Log a warning message in the case that "ENOKEY" is returned
+from the get_spnego_key upcall so that users can better understand
+why mount failed in those two cases.
+
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/cifs/smb2pdu.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/cifs/smb2pdu.c
++++ b/fs/cifs/smb2pdu.c
+@@ -1347,6 +1347,8 @@ SMB2_auth_kerberos(struct SMB2_sess_data
+ spnego_key = cifs_get_spnego_key(ses);
+ if (IS_ERR(spnego_key)) {
+ rc = PTR_ERR(spnego_key);
++ if (rc == -ENOKEY)
++ cifs_dbg(VFS, "Verify user has a krb5 ticket and keyutils is installed\n");
+ spnego_key = NULL;
+ goto out;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
