September 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] ata: libahci: clear pending interrupt status" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 737dd811a3dbfd7edd4ad2ba5152e93d99074f83 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023092019-aptitude-device-3909@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 737dd811a3db ("ata: libahci: clear pending interrupt status") 93c7711494f4 ("ata: ahci: Drop pointless VPRINTK() calls and convert the remaining ones") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 737dd811a3dbfd7edd4ad2ba5152e93d99074f83 Mon Sep 17 00:00:00 2001 From: Szuying Chen <chensiying21(a)gmail.com> Date: Thu, 7 Sep 2023 16:17:10 +0800 Subject: [PATCH] ata: libahci: clear pending interrupt status When a CRC error occurs, the HBA asserts an interrupt to indicate an interface fatal error (PxIS.IFS). The ISR clears PxIE and PxIS, then does error recovery. If the adapter receives another SDB FIS with an error (PxIS.TFES) from the device before the start of the EH recovery process, the interrupt signaling the new SDB cannot be serviced as PxIE was cleared already. This in turn results in the HBA inability to issue any command during the error recovery process after setting PxCMD.ST to 1 because PxIS.TFES is still set. According to AHCI 1.3.1 specifications section 6.2.2, fatal errors notified by setting PxIS.HBFS, PxIS.HBDS, PxIS.IFS or PxIS.TFES will cause the HBA to enter the ERR:Fatal state. In this state, the HBA shall not issue any new commands. To avoid this situation, introduce the function ahci_port_clear_pending_irq() to clear pending interrupts before executing a COMRESET. This follows the AHCI 1.3.1 - section 6.2.2.2 specification. Signed-off-by: Szuying Chen <Chloe_Chen(a)asmedia.com.tw> Fixes: e0bfd149973d ("[PATCH] ahci: stop engine during hard reset") Cc: stable(a)vger.kernel.org Reviewed-by: Niklas Cassel <niklas.cassel(a)wdc.com> Signed-off-by: Damien Le Moal <dlemoal(a)kernel.org> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index e2bacedf28ef..f1263364fa97 100644 --- a/drivers/ata/libahci.c +++ b/drivers/ata/libahci.c @@ -1256,6 +1256,26 @@ static ssize_t ahci_activity_show(struct ata_device *dev, char *buf) return sprintf(buf, "%d\n", emp->blink_policy); } +static void ahci_port_clear_pending_irq(struct ata_port *ap) +{ + struct ahci_host_priv *hpriv = ap->host->private_data; + void __iomem *port_mmio = ahci_port_base(ap); + u32 tmp; + + /* clear SError */ + tmp = readl(port_mmio + PORT_SCR_ERR); + dev_dbg(ap->host->dev, "PORT_SCR_ERR 0x%x\n", tmp); + writel(tmp, port_mmio + PORT_SCR_ERR); + + /* clear port IRQ */ + tmp = readl(port_mmio + PORT_IRQ_STAT); + dev_dbg(ap->host->dev, "PORT_IRQ_STAT 0x%x\n", tmp); + if (tmp) + writel(tmp, port_mmio + PORT_IRQ_STAT); + + writel(1 << ap->port_no, hpriv->mmio + HOST_IRQ_STAT); +} + static void ahci_port_init(struct device *dev, struct ata_port *ap, int port_no, void __iomem *mmio, void __iomem *port_mmio) @@ -1270,18 +1290,7 @@ static void ahci_port_init(struct device *dev, struct ata_port *ap, if (rc) dev_warn(dev, "%s (%d)\n", emsg, rc); - /* clear SError */ - tmp = readl(port_mmio + PORT_SCR_ERR); - dev_dbg(dev, "PORT_SCR_ERR 0x%x\n", tmp); - writel(tmp, port_mmio + PORT_SCR_ERR); - - /* clear port IRQ */ - tmp = readl(port_mmio + PORT_IRQ_STAT); - dev_dbg(dev, "PORT_IRQ_STAT 0x%x\n", tmp); - if (tmp) - writel(tmp, port_mmio + PORT_IRQ_STAT); - - writel(1 << port_no, mmio + HOST_IRQ_STAT); + ahci_port_clear_pending_irq(ap); /* mark esata ports */ tmp = readl(port_mmio + PORT_CMD); @@ -1603,6 +1612,8 @@ int ahci_do_hardreset(struct ata_link *link, unsigned int *class, tf.status = ATA_BUSY; ata_tf_to_fis(&tf, 0, 0, d2h_fis); + ahci_port_clear_pending_irq(ap); + rc = sata_link_hardreset(link, timing, deadline, online, ahci_check_ready);

1 year, 2 months

2
2
0 0

[PATCH 2/5] x86: KVM: SVM: add support for Invalid IPI Vector interception

by Maxim Levitsky

In later revisions of AMD's APM, there is a new 'incomplete IPI' exit code: "Invalid IPI Vector - The vector for the specified IPI was set to an illegal value (VEC < 16)" Note that tests on Zen2 machine show that this VM exit doesn't happen and instead AVIC just does nothing. Add support for this exit code by doing nothing, instead of filling the kernel log with errors. Also replace an unthrottled 'pr_err()' if another unknown incomplete IPI exit happens with WARN_ON_ONCE() (e.g in case AMD adds yet another 'Invalid IPI' exit reason) Cc: <stable(a)vger.kernel.org> Signed-off-by: Maxim Levitsky <mlevitsk(a)redhat.com> --- arch/x86/include/asm/svm.h | 1 + arch/x86/kvm/svm/avic.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h index 19bf955b67e0da0..3ac0ffc4f3e202b 100644 --- a/arch/x86/include/asm/svm.h +++ b/arch/x86/include/asm/svm.h @@ -268,6 +268,7 @@ enum avic_ipi_failure_cause { AVIC_IPI_FAILURE_TARGET_NOT_RUNNING, AVIC_IPI_FAILURE_INVALID_TARGET, AVIC_IPI_FAILURE_INVALID_BACKING_PAGE, + AVIC_IPI_FAILURE_INVALID_IPI_VECTOR, }; #define AVIC_PHYSICAL_MAX_INDEX_MASK GENMASK_ULL(8, 0) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index 2092db892d7d052..c44b65af494e3ff 100644 --- a/arch/x86/kvm/svm/avic.c +++ b/arch/x86/kvm/svm/avic.c @@ -529,8 +529,11 @@ int avic_incomplete_ipi_interception(struct kvm_vcpu *vcpu) case AVIC_IPI_FAILURE_INVALID_BACKING_PAGE: WARN_ONCE(1, "Invalid backing page\n"); break; + case AVIC_IPI_FAILURE_INVALID_IPI_VECTOR: + /* Invalid IPI with vector < 16 */ + break; default: - pr_err("Unknown IPI interception\n"); + WARN_ONCE(1, "Unknown avic incomplete IPI interception\n"); } return 1; -- 2.26.3

1 year, 2 months

2
1
0 0

[REGRESSION] EINVAL with mount in selinux_set_mnt_opts when mounting in a guest vm with selinux disabled

by Simon Kaegi

#regzbot introduced v6.1.52..v6.1.53 #regzbot introduced: ed134f284b4ed85a70d5f760ed0686e3cd555f9b We hit this regression when updating our guest vm kernel from 6.1.52 to 6.1.53 -- bisecting this problem was introduced in ed134f284b4ed85a70d5f760ed0686e3cd555f9b -- vfs, security: Fix automount superblock LSM init problem, preventing NFS sb sharing -- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… We're getting an EINVAL in `selinux_set_mnt_opts` in `security/selinux/hooks.c` when mounting a folder in a guest VM where selinux is disabled. We're mounting from another folder that we suspect has selinux labels set from the host. The EINVAL is getting set in the following block... ``` if (!selinux_initialized(&selinux_state)) { if (!opts) { /* Defer initialization until selinux_complete_init, after the initial policy is loaded and the security server is ready to handle calls. */ goto out; } rc = -EINVAL; pr_warn("SELinux: Unable to set superblock options " "before the security server is initialized\n"); goto out; } ``` We can reproduce 100% of the time but don't currently have a simple reproducer as the problem was found in our build service which uses kata-containers (with cloud-hypervisor and rootfs mounted via virtio-blk). We have not checked the mainline as we currently are tied to 6.1.x. -Simon

1 year, 2 months

3
4
0 0

[PATCH 6.4, 6.5] ASoC: cs35l56: Disable low-power hibernation mode

by Richard Fitzgerald

commit 18789be8e0d9fbb78b2290dcf93f500726ed19f0 upstream. Please apply to 6.4 and 6.5. Do not allow the CS35L56 to be put into its lowest power "hibernation" mode. This only affects I2C because "hibernation" is already disabled on SPI and SoundWire. Recent firmwares need a different wake-up sequence. Until that sequence has been specified, the chip "hibernation" mode must be disabled otherwise it can intermittently fail to wake. Backport note: This is the same change as upstream commit, to delete one line, but the upstream commit would not apply cleanly on older branches because of minor differences to the surrounding code. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20230912133841.3480466-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/cs35l56-i2c.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/codecs/cs35l56-i2c.c b/sound/soc/codecs/cs35l56-i2c.c index c613a2554fa3..494adabd4f43 100644 --- a/sound/soc/codecs/cs35l56-i2c.c +++ b/sound/soc/codecs/cs35l56-i2c.c @@ -27,7 +27,6 @@ static int cs35l56_i2c_probe(struct i2c_client *client) return -ENOMEM; cs35l56->dev = dev; - cs35l56->can_hibernate = true; i2c_set_clientdata(client, cs35l56); cs35l56->regmap = devm_regmap_init_i2c(client, regmap_config); -- 2.30.2

1 year, 2 months

2
1
0 0

[PATCH -stable,5.10 0/2] Netfilter stable fixes for 5.10

by Pablo Neira Ayuso

Hi Greg, Sasha, The following small batch contains two more fixes for a WARNING splat on chain unregistration and UaF in the flowtable unregistration that is exercised from netns path for 5.10 -stable. I am using original commit IDs for reference: 1) 6069da443bf6 ("netfilter: nf_tables: unregister flowtable hooks on netns exit") 2) f9a43007d3f7 ("netfilter: nf_tables: double hook unregistration in netns path") Please, apply. Thanks. Pablo Neira Ayuso (2): netfilter: nf_tables: unregister flowtable hooks on netns exit netfilter: nf_tables: double hook unregistration in netns path net/netfilter/nf_tables_api.c | 68 ++++++++++++++++++++++++++--------- 1 file changed, 52 insertions(+), 16 deletions(-) -- 2.30.2

1 year, 2 months

2
3
0 0

6.5 pre-emption hangs

by Mario Limonciello

Hi, Some hangs are reported on GFX9 hardware related to pre-emption. The hangs that are root caused to this are fixed by this commit from 6.6: 8cbbd11547f6 ("drm/amdgpu: set completion status as preempted for the resubmission") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2447#note_2100975 Can you please bring this back to 6.5.y? Thanks,

1 year, 2 months

2
1
0 0

[PATCH] drm/i915: Don't set PIPE_CONTROL_FLUSH_L3 for aux inval

by Nirmoy Das

PIPE_CONTROL_FLUSH_L3 is not needed for aux invalidation so don't set that. Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before invalidation") Cc: Jonathan Cavitt <jonathan.cavitt(a)intel.com> Cc: Andi Shyti <andi.shyti(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v5.8+ Cc: Andrzej Hajda <andrzej.hajda(a)intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Matt Roper <matthew.d.roper(a)intel.com> Cc: Tejas Upadhyay <tejas.upadhyay(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan(a)intel.com> Cc: Tapani Pälli <tapani.palli(a)intel.com> Cc: Mark Janes <mark.janes(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Signed-off-by: Nirmoy Das <nirmoy.das(a)intel.com> --- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c index 0143445dba83..ba4c2422b340 100644 --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c @@ -271,8 +271,17 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode) if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70)) bit_group_0 |= PIPE_CONTROL_CCS_FLUSH; + /* + * L3 fabric flush is needed for AUX CCS invalidation + * which happens as part of pipe-control so we can + * ignore PIPE_CONTROL_FLUSH_L3. Also PIPE_CONTROL_FLUSH_L3 + * deals with Protected Memory which is not needed for + * AUX CCS invalidation and lead to unwanted side effects. + */ + if (mode & EMIT_FLUSH) + bit_group_1 |= PIPE_CONTROL_FLUSH_L3; + bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH; - bit_group_1 |= PIPE_CONTROL_FLUSH_L3; bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; /* Wa_1409600907:tgl,adl-p */ -- 2.41.0

1 year, 2 months

6
6
0 0

[PATCH] x86/srso: Add SRSO mitigation for Hygon processors

by Pu Wen

From: Pu Wen <puwen(a)hygon.cn> Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors. Signed-off-by: Pu Wen <puwen(a)hygon.cn> Cc: <stable(a)vger.kernel.org> --- arch/x86/kernel/cpu/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 382d4e6b848d..4e5ffc8b0e46 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1303,7 +1303,7 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { VULNBL_AMD(0x15, RETBLEED), VULNBL_AMD(0x16, RETBLEED), VULNBL_AMD(0x17, RETBLEED | SMT_RSB | SRSO), - VULNBL_HYGON(0x18, RETBLEED | SMT_RSB), + VULNBL_HYGON(0x18, RETBLEED | SMT_RSB | SRSO), VULNBL_AMD(0x19, SRSO), {} }; -- 2.23.0

1 year, 2 months

3
2
0 0

Napływ Klientów ze strony

by Wiktor Nurek

Dzień dobry, chciałbym poinformować Państwa o możliwości pozyskania nowych zleceń ze strony www. Widzimy zainteresowanie potencjalnych Klientów Państwa firmą, dlatego chętnie pomożemy Państwu dotrzeć z ofertą do większego grona odbiorców poprzez efektywne metody pozycjonowania strony w Google. Czy mógłbym liczyć na kontakt zwrotny? Pozdrawiam serdecznie Wiktor Nurek

1 year, 2 months

1
0
0 0

[PATCH v3] firmware: qcom_scm: use 64-bit calling convention only when client is 64-bit

by Kathiravan Thirumoorthy

Per the "SMC calling convention specification", the 64-bit calling convention can only be used when the client is 64-bit. Whereas the 32-bit calling convention can be used by either a 32-bit or a 64-bit client. Currently during SCM probe, irrespective of the client, 64-bit calling convention is made, which is incorrect and may lead to the undefined behaviour when the client is 32-bit. Let's fix it. Cc: stable(a)vger.kernel.org Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Reviewed-By: Elliot Berman <quic_eberman(a)quicinc.com> Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav(a)quicinc.com> --- Changes in V3: - reworded the commit title and msg - pick up the R-b tag Changes in V2: - Added the Fixes tag and cc'd stable mailing list --- drivers/firmware/qcom_scm.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index c2c7fafef34b..520de9b5633a 100644 --- a/drivers/firmware/qcom_scm.c +++ b/drivers/firmware/qcom_scm.c @@ -215,6 +215,12 @@ static enum qcom_scm_convention __get_convention(void) if (likely(qcom_scm_convention != SMC_CONVENTION_UNKNOWN)) return qcom_scm_convention; + /* + * Per the "SMC calling convention specification", the 64-bit calling + * convention can only be used when the client is 64-bit, otherwise + * system will encounter the undefined behaviour. + */ +#if IS_ENABLED(CONFIG_ARM64) /* * Device isn't required as there is only one argument - no device * needed to dma_map_single to secure world @@ -235,6 +241,7 @@ static enum qcom_scm_convention __get_convention(void) forced = true; goto found; } +#endif probed_convention = SMC_CONVENTION_ARM_32; ret = __scm_smc_call(NULL, &desc, probed_convention, &res, true); --- base-commit: 8fff9184d1b5810dca5dd1a02726d4f844af88fc change-id: 20230925-scm-d62c6cd1947b Best regards, -- Kathiravan Thirumoorthy <quic_kathirav(a)quicinc.com>

1 year, 2 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2023