September 2024 - Linux-stable-mirror

[PATCH net] hv_netvsc: Fix VF namespace also in netvsc_open

by Haiyang Zhang

The existing code moves VF to the same namespace as the synthetic device during netvsc_register_vf(). But, if the synthetic device is moved to a new namespace after the VF registration, the VF won't be moved together. To make the behavior more consistent, add a namespace check to netvsc_open(), and move the VF if it is not in the same namespace. Cc: stable(a)vger.kernel.org Fixes: c0a41b887ce6 ("hv_netvsc: move VF to same namespace as netvsc device") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> --- drivers/net/hyperv/netvsc_drv.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 153b97f8ec0d..9caade092524 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -134,6 +134,19 @@ static int netvsc_open(struct net_device *net) } if (vf_netdev) { + if (!net_eq(dev_net(net), dev_net(vf_netdev))) { + ret = dev_change_net_namespace(vf_netdev, dev_net(net), + "eth%d"); + if (ret) + netdev_err(vf_netdev, + "Cannot move to same namespace as %s: %d\n", + net->name, ret); + else + netdev_info(vf_netdev, + "Moved VF to namespace with: %s\n", + net->name); + } + /* Setting synthetic device up transparently sets * slave as up. If open fails, then slave will be * still be offline (and not used). -- 2.34.1

9 months, 1 week

3
4
0 0

[PATCH v5 2/5] tpm: Implement tpm2_load_null() rollback

by Jarkko Sakkinen

tpm2_load_null() has weak and broken error handling: - The return value of tpm2_create_primary() is ignored. - Leaks TPM return codes from tpm2_load_context() to the caller. - If the key name comparison succeeds returns previous error instead of zero to the caller. Implement a proper error rollback. Cc: stable(a)vger.kernel.org # v6.10+ Fixes: eb24c9788cd9 ("tpm: disable the TPM if NULL name changes") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- v5: - Fix the TPM error code leak from tpm2_load_context(). v4: - No changes. v3: - Update log messages. Previously the log message incorrectly stated on load failure that integrity check had been failed, even tho the check is done *after* the load operation. v2: - Refined the commit message. - Reverted tpm2_create_primary() changes. They are not required if tmp_null_key is used as the parameter. --- drivers/char/tpm/tpm2-sessions.c | 43 +++++++++++++++++--------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c index 0f09ac33ae99..a856adef18d3 100644 --- a/drivers/char/tpm/tpm2-sessions.c +++ b/drivers/char/tpm/tpm2-sessions.c @@ -915,33 +915,36 @@ static int tpm2_parse_start_auth_session(struct tpm2_auth *auth, static int tpm2_load_null(struct tpm_chip *chip, u32 *null_key) { - int rc; unsigned int offset = 0; /* dummy offset for null seed context */ u8 name[SHA256_DIGEST_SIZE + 2]; + u32 tmp_null_key; + int rc; rc = tpm2_load_context(chip, chip->null_key_context, &offset, - null_key); - if (rc != -EINVAL) - return rc; + &tmp_null_key); + if (rc != -EINVAL) { + if (!rc) + *null_key = tmp_null_key; + goto err; + } - /* an integrity failure may mean the TPM has been reset */ - dev_err(&chip->dev, "NULL key integrity failure!\n"); - /* check the null name against what we know */ - tpm2_create_primary(chip, TPM2_RH_NULL, NULL, name); - if (memcmp(name, chip->null_key_name, sizeof(name)) == 0) - /* name unchanged, assume transient integrity failure */ - return rc; - /* - * Fatal TPM failure: the NULL seed has actually changed, so - * the TPM must have been illegally reset. All in-kernel TPM - * operations will fail because the NULL primary can't be - * loaded to salt the sessions, but disable the TPM anyway so - * userspace programmes can't be compromised by it. - */ - dev_err(&chip->dev, "NULL name has changed, disabling TPM due to interference\n"); + rc = tpm2_create_primary(chip, TPM2_RH_NULL, &tmp_null_key, name); + if (rc) + goto err; + + /* Return the null key if the name has not been changed: */ + if (memcmp(name, chip->null_key_name, sizeof(name)) == 0) { + *null_key = tmp_null_key; + return 0; + } + + /* Deduce from the name change TPM interference: */ + dev_err(&chip->dev, "the null key integrity check failedh\n"); + tpm2_flush_context(chip, tmp_null_key); chip->flags |= TPM_CHIP_FLAG_DISABLE; - return rc; +err: + return rc ? -ENODEV : rc; } /** -- 2.46.1

9 months, 1 week

2
1
0 0

[PATCH -fixes] riscv: Fix kernel stack size when KASAN is enabled

by Alexandre Ghiti

We use Kconfig to select the kernel stack size, doubling the default size if KASAN is enabled. But that actually only works if KASAN is selected from the beginning, meaning that if KASAN config is added later (for example using menuconfig), CONFIG_THREAD_SIZE_ORDER won't be updated, keeping the default size, which is not enough for KASAN as reported in [1]. So fix this by moving the logic to compute the right kernel stack into a header. Fixes: a7555f6b62e7 ("riscv: stack: Add config of thread stack size") Reported-by: syzbot+ba9eac24453387a9d502(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000eb301906222aadc2@google.com/ [1] Cc: stable(a)vger.kernel.org Signed-off-by: Alexandre Ghiti <alexghiti(a)rivosinc.com> --- arch/riscv/Kconfig | 3 +-- arch/riscv/include/asm/thread_info.h | 7 ++++++- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index ccbfd28f4982..b65846d02622 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -759,8 +759,7 @@ config IRQ_STACKS config THREAD_SIZE_ORDER int "Kernel stack size (in power-of-two numbers of page size)" if VMAP_STACK && EXPERT range 0 4 - default 1 if 32BIT && !KASAN - default 3 if 64BIT && KASAN + default 1 if 32BIT default 2 help Specify the Pages of thread stack size (from 4KB to 64KB), which also diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/asm/thread_info.h index fca5c6be2b81..385b43211a71 100644 --- a/arch/riscv/include/asm/thread_info.h +++ b/arch/riscv/include/asm/thread_info.h @@ -13,7 +13,12 @@ #include <linux/sizes.h> /* thread information allocation */ -#define THREAD_SIZE_ORDER CONFIG_THREAD_SIZE_ORDER +#ifdef CONFIG_KASAN +#define KASAN_STACK_ORDER 1 +#else +#define KASAN_STACK_ORDER 0 +#endif +#define THREAD_SIZE_ORDER (CONFIG_THREAD_SIZE_ORDER + KASAN_STACK_ORDER) #define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER) /* -- 2.39.2

9 months, 1 week

2
1
0 0

[PATCH v2] bus: mhi: host: free buffer on error in mhi_alloc_bhie_table

by Fedor Pchelkin

img_info->mhi_buf should be freed on error path in mhi_alloc_bhie_table(). This error case is rare but still needs to be fixed. Found by Linux Verification Center (linuxtesting.org). Fixes: 3000f85b8f47 ("bus: mhi: core: Add support for basic PM operations") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- v2: add missing Cc: stable, as Greg Kroah-Hartman's bot reported drivers/bus/mhi/host/boot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bus/mhi/host/boot.c b/drivers/bus/mhi/host/boot.c index edc0ec5a0933..738dcd11b66f 100644 --- a/drivers/bus/mhi/host/boot.c +++ b/drivers/bus/mhi/host/boot.c @@ -357,6 +357,7 @@ int mhi_alloc_bhie_table(struct mhi_controller *mhi_cntrl, for (--i, --mhi_buf; i >= 0; i--, mhi_buf--) dma_free_coherent(mhi_cntrl->cntrl_dev, mhi_buf->len, mhi_buf->buf, mhi_buf->dma_addr); + kfree(img_info->mhi_buf); error_alloc_mhi_buf: kfree(img_info); -- 2.39.2

9 months, 1 week

2
2
0 0

[PATCH net] vrf: revert "vrf: Remove unnecessary RCU-bh critical section"

by Willem de Bruijn

From: Willem de Bruijn <willemb(a)google.com> This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: ================================ WARNING: inconsistent lock state 6.11.0 #1 Tainted: G W -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} state was registered at: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(rlock-AF_PACKET); <Interrupt> lock(rlock-AF_PACKET); *** DEADLOCK *** Call Trace: <TASK> dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 tpacket_rcv+0x863/0x3b30 dev_queue_xmit_nit+0x709/0xa40 vrf_finish_direct+0x26e/0x340 [vrf] vrf_l3_out+0x5f4/0xe80 [vrf] __ip_local_out+0x51e/0x7a0 [...] Fixes: 504fc6f4f7f6 ("vrf: Remove unnecessary RCU-bh critical section") Link: https://lore.kernel.org/netdev/20240925185216.1990381-1-greearb@candelatech… Reported-by: Ben Greear <greearb(a)candelatech.com> Signed-off-by: Willem de Bruijn <willemb(a)google.com> Cc: stable(a)vger.kernel.org --- drivers/net/vrf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index 4d8ccaf9a2b4..4087f72f0d2b 100644 --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -608,7 +608,9 @@ static void vrf_finish_direct(struct sk_buff *skb) eth_zero_addr(eth->h_dest); eth->h_proto = skb->protocol; + rcu_read_lock_bh(); dev_queue_xmit_nit(skb, vrf_dev); + rcu_read_unlock_bh(); skb_pull(skb, ETH_HLEN); } -- 2.46.1.824.gd892dcdcdd-goog

9 months, 1 week

4
4
0 0

[PATCH] Revert "mmc: mvsdio: Use sg_miter for PIO"

by Linus Walleij

This reverts commit 2761822c00e8c271f10a10affdbd4917d900d7ea. When testing on real hardware the patch does not work. Revert, try to acquire real hardware, and retry. These systems typically don't have highmem anyway so the impact is likely zero. Cc: stable(a)vger.kernel.org Reported-by: Charlie <g4sra(a)protonmail.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/mmc/host/mvsdio.c | 71 ++++++++++++----------------------------------- 1 file changed, 18 insertions(+), 53 deletions(-) diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c index af7f21888e27..ca01b7d204ba 100644 --- a/drivers/mmc/host/mvsdio.c +++ b/drivers/mmc/host/mvsdio.c @@ -38,9 +38,8 @@ struct mvsd_host { unsigned int xfer_mode; unsigned int intr_en; unsigned int ctrl; - bool use_pio; - struct sg_mapping_iter sg_miter; unsigned int pio_size; + void *pio_ptr; unsigned int sg_frags; unsigned int ns_per_clk; unsigned int clock; @@ -115,18 +114,11 @@ static int mvsd_setup_data(struct mvsd_host *host, struct mmc_data *data) * data when the buffer is not aligned on a 64 byte * boundary. */ - unsigned int miter_flags = SG_MITER_ATOMIC; /* Used from IRQ */ - - if (data->flags & MMC_DATA_READ) - miter_flags |= SG_MITER_TO_SG; - else - miter_flags |= SG_MITER_FROM_SG; - host->pio_size = data->blocks * data->blksz; - sg_miter_start(&host->sg_miter, data->sg, data->sg_len, miter_flags); + host->pio_ptr = sg_virt(data->sg); if (!nodma) - dev_dbg(host->dev, "fallback to PIO for data\n"); - host->use_pio = true; + dev_dbg(host->dev, "fallback to PIO for data at 0x%p size %d\n", + host->pio_ptr, host->pio_size); return 1; } else { dma_addr_t phys_addr; @@ -137,7 +129,6 @@ static int mvsd_setup_data(struct mvsd_host *host, struct mmc_data *data) phys_addr = sg_dma_address(data->sg); mvsd_write(MVSD_SYS_ADDR_LOW, (u32)phys_addr & 0xffff); mvsd_write(MVSD_SYS_ADDR_HI, (u32)phys_addr >> 16); - host->use_pio = false; return 0; } } @@ -297,8 +288,8 @@ static u32 mvsd_finish_data(struct mvsd_host *host, struct mmc_data *data, { void __iomem *iobase = host->base; - if (host->use_pio) { - sg_miter_stop(&host->sg_miter); + if (host->pio_ptr) { + host->pio_ptr = NULL; host->pio_size = 0; } else { dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->sg_frags, @@ -353,12 +344,9 @@ static u32 mvsd_finish_data(struct mvsd_host *host, struct mmc_data *data, static irqreturn_t mvsd_irq(int irq, void *dev) { struct mvsd_host *host = dev; - struct sg_mapping_iter *sgm = &host->sg_miter; void __iomem *iobase = host->base; u32 intr_status, intr_done_mask; int irq_handled = 0; - u16 *p; - int s; intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); dev_dbg(host->dev, "intr 0x%04x intr_en 0x%04x hw_state 0x%04x\n", @@ -382,36 +370,15 @@ static irqreturn_t mvsd_irq(int irq, void *dev) spin_lock(&host->lock); /* PIO handling, if needed. Messy business... */ - if (host->use_pio) { - /* - * As we set sgm->consumed this always gives a valid buffer - * position. - */ - if (!sg_miter_next(sgm)) { - /* This should not happen */ - dev_err(host->dev, "ran out of scatter segments\n"); - spin_unlock(&host->lock); - host->intr_en &= - ~(MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W | - MVSD_NOR_TX_AVAIL | MVSD_NOR_TX_FIFO_8W); - mvsd_write(MVSD_NOR_INTR_EN, host->intr_en); - return IRQ_HANDLED; - } - p = sgm->addr; - s = sgm->length; - if (s > host->pio_size) - s = host->pio_size; - } - - if (host->use_pio && + if (host->pio_size && (intr_status & host->intr_en & (MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W))) { - + u16 *p = host->pio_ptr; + int s = host->pio_size; while (s >= 32 && (intr_status & MVSD_NOR_RX_FIFO_8W)) { readsw(iobase + MVSD_FIFO, p, 16); p += 16; s -= 32; - sgm->consumed += 32; intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); } /* @@ -424,7 +391,6 @@ static irqreturn_t mvsd_irq(int irq, void *dev) put_unaligned(mvsd_read(MVSD_FIFO), p++); put_unaligned(mvsd_read(MVSD_FIFO), p++); s -= 4; - sgm->consumed += 4; intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); } if (s && s < 4 && (intr_status & MVSD_NOR_RX_READY)) { @@ -432,13 +398,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev) val[0] = mvsd_read(MVSD_FIFO); val[1] = mvsd_read(MVSD_FIFO); memcpy(p, ((void *)&val) + 4 - s, s); - sgm->consumed += s; s = 0; intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); } - /* PIO transfer done */ - host->pio_size -= sgm->consumed; - if (host->pio_size == 0) { + if (s == 0) { host->intr_en &= ~(MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W); mvsd_write(MVSD_NOR_INTR_EN, host->intr_en); @@ -450,10 +413,14 @@ static irqreturn_t mvsd_irq(int irq, void *dev) } dev_dbg(host->dev, "pio %d intr 0x%04x hw_state 0x%04x\n", s, intr_status, mvsd_read(MVSD_HW_STATE)); + host->pio_ptr = p; + host->pio_size = s; irq_handled = 1; - } else if (host->use_pio && + } else if (host->pio_size && (intr_status & host->intr_en & (MVSD_NOR_TX_AVAIL | MVSD_NOR_TX_FIFO_8W))) { + u16 *p = host->pio_ptr; + int s = host->pio_size; /* * The TX_FIFO_8W bit is unreliable. When set, bursting * 16 halfwords all at once in the FIFO drops data. Actually @@ -464,7 +431,6 @@ static irqreturn_t mvsd_irq(int irq, void *dev) mvsd_write(MVSD_FIFO, get_unaligned(p++)); mvsd_write(MVSD_FIFO, get_unaligned(p++)); s -= 4; - sgm->consumed += 4; intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); } if (s < 4) { @@ -473,13 +439,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev) memcpy(((void *)&val) + 4 - s, p, s); mvsd_write(MVSD_FIFO, val[0]); mvsd_write(MVSD_FIFO, val[1]); - sgm->consumed += s; s = 0; intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); } - /* PIO transfer done */ - host->pio_size -= sgm->consumed; - if (host->pio_size == 0) { + if (s == 0) { host->intr_en &= ~(MVSD_NOR_TX_AVAIL | MVSD_NOR_TX_FIFO_8W); mvsd_write(MVSD_NOR_INTR_EN, host->intr_en); @@ -487,6 +450,8 @@ static irqreturn_t mvsd_irq(int irq, void *dev) } dev_dbg(host->dev, "pio %d intr 0x%04x hw_state 0x%04x\n", s, intr_status, mvsd_read(MVSD_HW_STATE)); + host->pio_ptr = p; + host->pio_size = s; irq_handled = 1; } --- base-commit: 075dbe9f6e3c21596c5245826a4ee1f1c1676eb8 change-id: 20240927-kirkwood-mmc-regression-986c598d4c9e Best regards, -- Linus Walleij <linus.walleij(a)linaro.org>

9 months, 1 week

2
1
0 0

[regression] Regular "cracks" in HDMI sound during playback since backport to 6.1.y for 92afcc310038 ("ALSA: hda: Conditionally use snooping for AMD HDMI")

by Salvatore Bonaccorso

Hi In downstream Debian we got a report from Eric Degenetais, in https://bugs.debian.org/1081833 that after the update to the 6.1.106 based version, there were regular cracks in HDMI sound during playback. Eric was able to bisec the issue down to 92afcc310038ebe5d66c689bb0bf418f5451201c in the v6.1.y series which got applied in 6.1.104. Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081833#47 #regzbot introduced: 92afcc310038ebe5d66c689bb0bf418f5451201c #regzbot link: https://bugs.debian.org/1081833 It should be noted that Eric as well tried more recent stable series as well, in particular did test as well 6.10.6 based version back on 20th september, and the issue was reproducible there as well. Is there anything else we can try to provide? Regards, Salvatore

9 months, 1 week

3
3
0 0

[REGRESSION]: cephfs: file corruption when reading content via in-kernel ceph client

by Christian Ebner

Hi, some of our customers (Proxmox VE) are seeing issues with file corruptions when accessing contents located on CephFS via the in-kernel Ceph client [0,1], we managed to reproduce this regression on kernels up to the latest 6.11-rc6. Accessing the same content on the CephFS using the FUSE client or the in-kernel ceph client with older kernels (Ubuntu kernel on v6.5) does not show file corruptions. Unfortunately the corruption is hard to reproduce, seemingly only a small subset of files is affected. However, once a file is affected, the issue is persistent and can easily be reproduced. Bisection with the reproducer points to this commit: "92b6cc5d: netfs: Add iov_iters to (sub)requests to describe various buffers" Description of the issue: A file was copied from local filesystem to cephfs via: ``` cp /tmp/proxmox-backup-server_3.2-1.iso /mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso ``` * sha256sum on local filesystem:`1d19698e8f7e769cf0a0dcc7ba0018ef5416c5ec495d5e61313f9c84a4237607 /tmp/proxmox-backup-server_3.2-1.iso` * sha256sum on cephfs with kernel up to above commit: `1d19698e8f7e769cf0a0dcc7ba0018ef5416c5ec495d5e61313f9c84a4237607 /mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso` * sha256sum on cephfs with kernel after above commit: `89ad3620bf7b1e0913b534516cfbe48580efbaec944b79951e2c14e5e551f736 /mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso` * removing and/or recopying the file does not change the issue, the corrupt checksum remains the same. * accessing the same file from different clients results in the same output: the one with above patch applied do show the incorrect checksum, ones without the patch show the correct checksum. * the issue persists even across reboot of the ceph cluster and/or clients. * the file is indeed corrupt after reading, as verified by a `cmp -b`. Interestingly, the first 4M contain the correct data, the following 4M are read as all zeros, which differs from the original data. * the issue is related to the readahead size: mounting the cephfs with a `rasize=0` makes the issue disappear, same is true for sizes up to 128k (please note that the ranges as initially reported on the mailing list [3] are not correct for rasize [0..128k] the file is not corrupted). In the bugtracker issue [4] I attached a ftrace with "*ceph*" as filter while performing a read on the latest kernel 6.11-rc6 while performing ``` dd if=/mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso of=/tmp/test.out bs=8M count=1 ``` the relevant part shown by task `dd-26192`. Please let me know if I can provide further information or debug outputs in order to narrow down the issue. [0] https://forum.proxmox.com/threads/78340/post-676129 [1] https://forum.proxmox.com/threads/149249/ [2] https://forum.proxmox.com/threads/151291/ [3] https://lore.kernel.org/lkml/db686d0c-2f27-47c8-8c14-26969433b13b@proxmox.c… [4] https://bugzilla.kernel.org/show_bug.cgi?id=219237 #regzbot introduced: 92b6cc5d Regards, Christian Ebner

9 months, 1 week

4
9
0 0

[PATCH] irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()

by Nam Cao

It is possible that an interrupt is disabled and masked at the same time. When the interrupt is enabled again by enable_irq(), only plic_irq_enable() is called, not plic_irq_unmask(). The interrupt remains masked and never raises. An example where interrupt is both disabled and masked is when handle_fasteoi_irq() is the handler, and IRQS_ONESHOT is set. The interrupt handler: 1. Mask the interrupt 2. Handle the interrupt 3. Check if interrupt is still enabled, and unmask it (see cond_unmask_eoi_irq()) If another task disables the interrupt in the middle of the above steps, the interrupt will not get unmasked, and will remain masked when it is enabled in the future. The problem is occasionally observed when PREEMPT_RT is enabled, because PREEMPT_RT add the IRQS_ONESHOT flag. But PREEMPT_RT only makes the problem more likely to appear, the bug has been around since commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations"). Fix it by unmasking interrupt in plic_irq_enable(). Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations"). Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: stable(a)vger.kernel.org --- drivers/irqchip/irq-sifive-plic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c index 2f6ef5c495bd..0efbf14ec9fa 100644 --- a/drivers/irqchip/irq-sifive-plic.c +++ b/drivers/irqchip/irq-sifive-plic.c @@ -128,6 +128,9 @@ static inline void plic_irq_toggle(const struct cpumask *mask, static void plic_irq_enable(struct irq_data *d) { + struct plic_priv *priv = irq_data_get_irq_chip_data(d); + + writel(1, priv->regs + PRIORITY_BASE + d->hwirq * PRIORITY_PER_ID); plic_irq_toggle(irq_data_get_effective_affinity_mask(d), d, 1); } -- 2.39.5

9 months, 1 week

2
1
0 0

[PATCH] drm/panthor: Don't add write fences to the shared BOs

by Boris Brezillon

The only user (the mesa gallium driver) is already assuming explicit synchronization and doing the export/import dance on shared BOs. The only reason we were registering ourselves as writers on external BOs is because Xe, which was the reference back when we developed Panthor, was doing so. Turns out Xe was wrong, and we really want bookkeep on all registered fences, so userspace can explicitly upgrade those to read/write when needed. Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block") Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Simona Vetter <simona.vetter(a)ffwll.ch> Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- drivers/gpu/drm/panthor/panthor_sched.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c index 9a0ff48f7061..41260cf4beb8 100644 --- a/drivers/gpu/drm/panthor/panthor_sched.c +++ b/drivers/gpu/drm/panthor/panthor_sched.c @@ -3423,13 +3423,8 @@ void panthor_job_update_resvs(struct drm_exec *exec, struct drm_sched_job *sched { struct panthor_job *job = container_of(sched_job, struct panthor_job, base); - /* Still not sure why we want USAGE_WRITE for external objects, since I - * was assuming this would be handled through explicit syncs being imported - * to external BOs with DMA_BUF_IOCTL_IMPORT_SYNC_FILE, but other drivers - * seem to pass DMA_RESV_USAGE_WRITE, so there must be a good reason. - */ panthor_vm_update_resvs(job->group->vm, exec, &sched_job->s_fence->finished, - DMA_RESV_USAGE_BOOKKEEP, DMA_RESV_USAGE_WRITE); + DMA_RESV_USAGE_BOOKKEEP, DMA_RESV_USAGE_BOOKKEEP); } void panthor_sched_unplug(struct panthor_device *ptdev) -- 2.46.0

9 months, 1 week

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024