From: Greg Kroah-Hartman Date: Wed, 19 Aug 2020 10:20:11 +0000 (+0200) Subject: 5.7-stable patches X-Git-Tag: v4.14.194~62 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=48f607fc8e539a67a9e24365a8ea7bb8ad1f400a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.7-stable patches added patches: genirq-affinity-make-affinity-setting-if-activated-opt-in.patch genirq-pm-always-unlock-irq-descriptor-in-rearm_wake_irq.patch pci-hotplug-acpi-fix-context-refcounting-in-acpiphp_grab_context.patch smb3-warn-on-confusing-error-scenario-with-sec-krb5.patch --- diff --git a/queue-5.7/genirq-affinity-make-affinity-setting-if-activated-opt-in.patch b/queue-5.7/genirq-affinity-make-affinity-setting-if-activated-opt-in.patch new file mode 100644 index 00000000000..8e7803a4be4 --- /dev/null +++ b/queue-5.7/genirq-affinity-make-affinity-setting-if-activated-opt-in.patch @@ -0,0 +1,138 @@ +From f0c7baca180046824e07fc5f1326e83a8fd150c7 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Fri, 24 Jul 2020 22:44:41 +0200 +Subject: genirq/affinity: Make affinity setting if activated opt-in + +From: Thomas Gleixner + +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 +Signed-off-by: Thomas Gleixner +Tested-by: Marc Zyngier +Acked-by: Marc Zyngier +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/87blk4tzgm.fsf@nanos.tec.linutronix.de +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-5.7/genirq-pm-always-unlock-irq-descriptor-in-rearm_wake_irq.patch b/queue-5.7/genirq-pm-always-unlock-irq-descriptor-in-rearm_wake_irq.patch new file mode 100644 index 00000000000..b3617141115 --- /dev/null +++ b/queue-5.7/genirq-pm-always-unlock-irq-descriptor-in-rearm_wake_irq.patch @@ -0,0 +1,49 @@ +From e27b1636e9337d1a1d174b191e53d0f86421a822 Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Tue, 11 Aug 2020 11:00:01 -0700 +Subject: genirq/PM: Always unlock IRQ descriptor in rearm_wake_irq() + +From: Guenter Roeck + +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 +Signed-off-by: Thomas Gleixner +Acked-by: Rafael J. Wysocki +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200811180001.80203-1-linux@roeck-us.net +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-5.7/pci-hotplug-acpi-fix-context-refcounting-in-acpiphp_grab_context.patch b/queue-5.7/pci-hotplug-acpi-fix-context-refcounting-in-acpiphp_grab_context.patch new file mode 100644 index 00000000000..cd0091bacae --- /dev/null +++ b/queue-5.7/pci-hotplug-acpi-fix-context-refcounting-in-acpiphp_grab_context.patch @@ -0,0 +1,51 @@ +From dae68d7fd4930315389117e9da35b763f12238f9 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Fri, 26 Jun 2020 19:42:34 +0200 +Subject: PCI: hotplug: ACPI: Fix context refcounting in acpiphp_grab_context() + +From: Rafael J. Wysocki + +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 +Cc: 3.15+ # 3.15+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-5.7/series b/queue-5.7/series index c3071eed58f..66249059811 100644 --- a/queue-5.7/series +++ b/queue-5.7/series @@ -1,3 +1,4 @@ smb3-warn-on-confusing-error-scenario-with-sec-krb5.patch genirq-affinity-make-affinity-setting-if-activated-opt-in.patch genirq-pm-always-unlock-irq-descriptor-in-rearm_wake_irq.patch +pci-hotplug-acpi-fix-context-refcounting-in-acpiphp_grab_context.patch diff --git a/queue-5.7/smb3-warn-on-confusing-error-scenario-with-sec-krb5.patch b/queue-5.7/smb3-warn-on-confusing-error-scenario-with-sec-krb5.patch new file mode 100644 index 00000000000..249b5948378 --- /dev/null +++ b/queue-5.7/smb3-warn-on-confusing-error-scenario-with-sec-krb5.patch @@ -0,0 +1,35 @@ +From 0a018944eee913962bce8ffebbb121960d5125d9 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Thu, 16 Jul 2020 00:34:21 -0500 +Subject: smb3: warn on confusing error scenario with sec=krb5 + +From: Steve French + +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 +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + }