January 2023 - Linux-stable-mirror

patch "VMCI: Use threaded irqs instead of tasklets" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled VMCI: Use threaded irqs instead of tasklets to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From 3daed6345d5880464f46adab871d208e1baa2f3a Mon Sep 17 00:00:00 2001 From: Vishnu Dasa <vdasa(a)vmware.com> Date: Tue, 29 Nov 2022 23:05:11 -0800 Subject: VMCI: Use threaded irqs instead of tasklets The vmci_dispatch_dgs() tasklet function calls vmci_read_data() which uses wait_event() resulting in invalid sleep in an atomic context (and therefore potentially in a deadlock). Use threaded irqs to fix this issue and completely remove usage of tasklets. [ 20.264639] BUG: sleeping function called from invalid context at drivers/misc/vmw_vmci/vmci_guest.c:145 [ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd [ 20.264645] preempt_count: 101, expected: 0 [ 20.264646] RCU nest depth: 0, expected: 0 [ 20.264647] 1 lock held by vmtoolsd/762: [ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: vsock_connect+0x60/0x330 [vsock] [ 20.264658] Preemption disabled at: [ 20.264659] [<ffff80000151d7d8>] vmci_send_datagram+0x44/0xa0 [vmw_vmci] [ 20.264665] CPU: 0 PID: 762 Comm: vmtoolsd Not tainted 5.19.0-0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1 [ 20.264667] Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020 [ 20.264668] Call trace: [ 20.264669] dump_backtrace+0xc4/0x130 [ 20.264672] show_stack+0x24/0x80 [ 20.264673] dump_stack_lvl+0x88/0xb4 [ 20.264676] dump_stack+0x18/0x34 [ 20.264677] __might_resched+0x1a0/0x280 [ 20.264679] __might_sleep+0x58/0x90 [ 20.264681] vmci_read_data+0x74/0x120 [vmw_vmci] [ 20.264683] vmci_dispatch_dgs+0x64/0x204 [vmw_vmci] [ 20.264686] tasklet_action_common.constprop.0+0x13c/0x150 [ 20.264688] tasklet_action+0x40/0x50 [ 20.264689] __do_softirq+0x23c/0x6b4 [ 20.264690] __irq_exit_rcu+0x104/0x214 [ 20.264691] irq_exit_rcu+0x1c/0x50 [ 20.264693] el1_interrupt+0x38/0x6c [ 20.264695] el1h_64_irq_handler+0x18/0x24 [ 20.264696] el1h_64_irq+0x68/0x6c [ 20.264697] preempt_count_sub+0xa4/0xe0 [ 20.264698] _raw_spin_unlock_irqrestore+0x64/0xb0 [ 20.264701] vmci_send_datagram+0x7c/0xa0 [vmw_vmci] [ 20.264703] vmci_datagram_dispatch+0x84/0x100 [vmw_vmci] [ 20.264706] vmci_datagram_send+0x2c/0x40 [vmw_vmci] [ 20.264709] vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport] [ 20.264711] vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport] [ 20.264713] vsock_connect+0x278/0x330 [vsock] [ 20.264715] __sys_connect_file+0x8c/0xc0 [ 20.264718] __sys_connect+0x84/0xb4 [ 20.264720] __arm64_sys_connect+0x2c/0x3c [ 20.264721] invoke_syscall+0x78/0x100 [ 20.264723] el0_svc_common.constprop.0+0x68/0x124 [ 20.264724] do_el0_svc+0x38/0x4c [ 20.264725] el0_svc+0x60/0x180 [ 20.264726] el0t_64_sync_handler+0x11c/0x150 [ 20.264728] el0t_64_sync+0x190/0x194 Signed-off-by: Vishnu Dasa <vdasa(a)vmware.com> Suggested-by: Zack Rusin <zackr(a)vmware.com> Reported-by: Nadav Amit <namit(a)vmware.com> Reported-by: Nathan Chancellor <nathan(a)kernel.org> Tested-by: Nathan Chancellor <nathan(a)kernel.org> Fixes: 463713eb6164 ("VMCI: dma dg: add support for DMA datagrams receive") Cc: <stable(a)vger.kernel.org> # v5.18+ Cc: VMware PV-Drivers Reviewers <pv-drivers(a)vmware.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Bryan Tan <bryantan(a)vmware.com> Reviewed-by: Bryan Tan <bryantan(a)vmware.com> Reviewed-by: Zack Rusin <zackr(a)vmware.com> Link: https://lore.kernel.org/r/20221130070511.46558-1-vdasa@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/vmw_vmci/vmci_guest.c | 49 ++++++++++++------------------ 1 file changed, 19 insertions(+), 30 deletions(-) diff --git a/drivers/misc/vmw_vmci/vmci_guest.c b/drivers/misc/vmw_vmci/vmci_guest.c index aa7b05de97dd..4f8d962bb5b2 100644 --- a/drivers/misc/vmw_vmci/vmci_guest.c +++ b/drivers/misc/vmw_vmci/vmci_guest.c @@ -56,8 +56,6 @@ struct vmci_guest_device { bool exclusive_vectors; - struct tasklet_struct datagram_tasklet; - struct tasklet_struct bm_tasklet; struct wait_queue_head inout_wq; void *data_buffer; @@ -304,9 +302,8 @@ static int vmci_check_host_caps(struct pci_dev *pdev) * This function assumes that it has exclusive access to the data * in register(s) for the duration of the call. */ -static void vmci_dispatch_dgs(unsigned long data) +static void vmci_dispatch_dgs(struct vmci_guest_device *vmci_dev) { - struct vmci_guest_device *vmci_dev = (struct vmci_guest_device *)data; u8 *dg_in_buffer = vmci_dev->data_buffer; struct vmci_datagram *dg; size_t dg_in_buffer_size = VMCI_MAX_DG_SIZE; @@ -465,10 +462,8 @@ static void vmci_dispatch_dgs(unsigned long data) * Scans the notification bitmap for raised flags, clears them * and handles the notifications. */ -static void vmci_process_bitmap(unsigned long data) +static void vmci_process_bitmap(struct vmci_guest_device *dev) { - struct vmci_guest_device *dev = (struct vmci_guest_device *)data; - if (!dev->notification_bitmap) { dev_dbg(dev->dev, "No bitmap present in %s\n", __func__); return; @@ -486,13 +481,13 @@ static irqreturn_t vmci_interrupt(int irq, void *_dev) struct vmci_guest_device *dev = _dev; /* - * If we are using MSI-X with exclusive vectors then we simply schedule - * the datagram tasklet, since we know the interrupt was meant for us. + * If we are using MSI-X with exclusive vectors then we simply call + * vmci_dispatch_dgs(), since we know the interrupt was meant for us. * Otherwise we must read the ICR to determine what to do. */ if (dev->exclusive_vectors) { - tasklet_schedule(&dev->datagram_tasklet); + vmci_dispatch_dgs(dev); } else { unsigned int icr; @@ -502,12 +497,12 @@ static irqreturn_t vmci_interrupt(int irq, void *_dev) return IRQ_NONE; if (icr & VMCI_ICR_DATAGRAM) { - tasklet_schedule(&dev->datagram_tasklet); + vmci_dispatch_dgs(dev); icr &= ~VMCI_ICR_DATAGRAM; } if (icr & VMCI_ICR_NOTIFICATION) { - tasklet_schedule(&dev->bm_tasklet); + vmci_process_bitmap(dev); icr &= ~VMCI_ICR_NOTIFICATION; } @@ -536,7 +531,7 @@ static irqreturn_t vmci_interrupt_bm(int irq, void *_dev) struct vmci_guest_device *dev = _dev; /* For MSI-X we can just assume it was meant for us. */ - tasklet_schedule(&dev->bm_tasklet); + vmci_process_bitmap(dev); return IRQ_HANDLED; } @@ -638,10 +633,6 @@ static int vmci_guest_probe_device(struct pci_dev *pdev, vmci_dev->iobase = iobase; vmci_dev->mmio_base = mmio_base; - tasklet_init(&vmci_dev->datagram_tasklet, - vmci_dispatch_dgs, (unsigned long)vmci_dev); - tasklet_init(&vmci_dev->bm_tasklet, - vmci_process_bitmap, (unsigned long)vmci_dev); init_waitqueue_head(&vmci_dev->inout_wq); if (mmio_base != NULL) { @@ -808,8 +799,9 @@ static int vmci_guest_probe_device(struct pci_dev *pdev, * Request IRQ for legacy or MSI interrupts, or for first * MSI-X vector. */ - error = request_irq(pci_irq_vector(pdev, 0), vmci_interrupt, - IRQF_SHARED, KBUILD_MODNAME, vmci_dev); + error = request_threaded_irq(pci_irq_vector(pdev, 0), NULL, + vmci_interrupt, IRQF_SHARED, + KBUILD_MODNAME, vmci_dev); if (error) { dev_err(&pdev->dev, "Irq %u in use: %d\n", pci_irq_vector(pdev, 0), error); @@ -823,9 +815,9 @@ static int vmci_guest_probe_device(struct pci_dev *pdev, * between the vectors. */ if (vmci_dev->exclusive_vectors) { - error = request_irq(pci_irq_vector(pdev, 1), - vmci_interrupt_bm, 0, KBUILD_MODNAME, - vmci_dev); + error = request_threaded_irq(pci_irq_vector(pdev, 1), NULL, + vmci_interrupt_bm, 0, + KBUILD_MODNAME, vmci_dev); if (error) { dev_err(&pdev->dev, "Failed to allocate irq %u: %d\n", @@ -833,9 +825,11 @@ static int vmci_guest_probe_device(struct pci_dev *pdev, goto err_free_irq; } if (caps_in_use & VMCI_CAPS_DMA_DATAGRAM) { - error = request_irq(pci_irq_vector(pdev, 2), - vmci_interrupt_dma_datagram, - 0, KBUILD_MODNAME, vmci_dev); + error = request_threaded_irq(pci_irq_vector(pdev, 2), + NULL, + vmci_interrupt_dma_datagram, + 0, KBUILD_MODNAME, + vmci_dev); if (error) { dev_err(&pdev->dev, "Failed to allocate irq %u: %d\n", @@ -871,8 +865,6 @@ static int vmci_guest_probe_device(struct pci_dev *pdev, err_free_irq: free_irq(pci_irq_vector(pdev, 0), vmci_dev); - tasklet_kill(&vmci_dev->datagram_tasklet); - tasklet_kill(&vmci_dev->bm_tasklet); err_disable_msi: pci_free_irq_vectors(pdev); @@ -943,9 +935,6 @@ static void vmci_guest_remove_device(struct pci_dev *pdev) free_irq(pci_irq_vector(pdev, 0), vmci_dev); pci_free_irq_vectors(pdev); - tasklet_kill(&vmci_dev->datagram_tasklet); - tasklet_kill(&vmci_dev->bm_tasklet); - if (vmci_dev->notification_bitmap) { /* * The device reset above cleared the bitmap state of the -- 2.39.1

2 years, 1 month

1
0
0 0

patch "mei: me: add meteor lake point M DID" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: me: add meteor lake point M DID to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From 0c4d68261717f89fa8c4f98a6967c3832fcb3ad0 Mon Sep 17 00:00:00 2001 From: Alexander Usyskin <alexander.usyskin(a)intel.com> Date: Tue, 13 Dec 2022 00:02:47 +0200 Subject: mei: me: add meteor lake point M DID Add Meteor Lake Point M device id. Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Link: https://lore.kernel.org/r/20221212220247.286019-2-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/hw-me-regs.h | 2 ++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h index 99966cd3e7d8..bdc65d50b945 100644 --- a/drivers/misc/mei/hw-me-regs.h +++ b/drivers/misc/mei/hw-me-regs.h @@ -111,6 +111,8 @@ #define MEI_DEV_ID_RPL_S 0x7A68 /* Raptor Lake Point S */ +#define MEI_DEV_ID_MTL_M 0x7E70 /* Meteor Lake Point M */ + /* * MEI HW Section */ diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index 704cd0caa172..5bf0d50d55a0 100644 --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -118,6 +118,8 @@ static const struct pci_device_id mei_me_pci_tbl[] = { {MEI_PCI_DEVICE(MEI_DEV_ID_RPL_S, MEI_ME_PCH15_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_MTL_M, MEI_ME_PCH15_CFG)}, + /* required last entry */ {0, } }; -- 2.39.1

2 years, 1 month

1
0
0 0

patch "mei: bus: fix unlink on bus in error path" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: bus: fix unlink on bus in error path to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From a43866856125c3c432e2fbb6cc63cee1539ec4a7 Mon Sep 17 00:00:00 2001 From: Alexander Usyskin <alexander.usyskin(a)intel.com> Date: Tue, 13 Dec 2022 00:02:46 +0200 Subject: mei: bus: fix unlink on bus in error path Unconditional call to mei_cl_unlink in mei_cl_bus_dev_release leads to call of the mei_cl_unlink without corresponding mei_cl_link. This leads to miscalculation of open_handle_count (decrease without increase). Call unlink in mei_cldev_enable fail path and remove blanket unlink from mei_cl_bus_dev_release. Fixes: 34f1166afd67 ("mei: bus: need to unlink client before freeing") Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Reviewed-by: Tomas Winkler <tomas.winkler(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Link: https://lore.kernel.org/r/20221212220247.286019-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/bus.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index 4a08b624910a..a81b890c7ee6 100644 --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -702,13 +702,15 @@ void *mei_cldev_dma_map(struct mei_cl_device *cldev, u8 buffer_id, size_t size) if (cl->state == MEI_FILE_UNINITIALIZED) { ret = mei_cl_link(cl); if (ret) - goto out; + goto notlinked; /* update pointers */ cl->cldev = cldev; } ret = mei_cl_dma_alloc_and_map(cl, NULL, buffer_id, size); -out: + if (ret) + mei_cl_unlink(cl); +notlinked: mutex_unlock(&bus->device_lock); if (ret) return ERR_PTR(ret); @@ -758,7 +760,7 @@ int mei_cldev_enable(struct mei_cl_device *cldev) if (cl->state == MEI_FILE_UNINITIALIZED) { ret = mei_cl_link(cl); if (ret) - goto out; + goto notlinked; /* update pointers */ cl->cldev = cldev; } @@ -785,6 +787,9 @@ int mei_cldev_enable(struct mei_cl_device *cldev) } out: + if (ret) + mei_cl_unlink(cl); +notlinked: mutex_unlock(&bus->device_lock); return ret; @@ -1277,7 +1282,6 @@ static void mei_cl_bus_dev_release(struct device *dev) mei_cl_flush_queues(cldev->cl, NULL); mei_me_cl_put(cldev->me_cl); mei_dev_bus_put(cldev->bus); - mei_cl_unlink(cldev->cl); kfree(cldev->cl); kfree(cldev); } -- 2.39.1

2 years, 1 month

1
0
0 0

[PATCH] btrfs: limit device extents to the device size

by Josef Bacik

There was a recent regression in btrfs/177 that started happening with the size class patches. This however isn't a regression introduced by those patches, but rather the bug was uncovered by a change in behavior in these patches. The patches triggered more chunk allocations in the ^free-space-tree case, which uncovered a race with device shrink. The problem is we will set the device total size to the new size, and use this to find a hole for a device extent. However during shrink we may have device extents allocated past this range, so we could potentially find a hole in a range past our new shrink size. We don't actually limit our found extent to the device size anywhere, we assume that we will not find a hole past our device size. This isn't true with shrink as we're relocating block groups and thus creating holes past the device size. Fix this by making sure we do not search past the new device size, and if we wander into any device extents that start after our device size simply break from the loop and use whatever hole we've already found. cc: stable(a)vger.kernel.org Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> --- fs/btrfs/volumes.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 675598c3cb35..707dd0456cea 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1600,7 +1600,7 @@ static int find_free_dev_extent_start(struct btrfs_device *device, if (ret < 0) goto out; - while (1) { + while (search_start < search_end) { l = path->nodes[0]; slot = path->slots[0]; if (slot >= btrfs_header_nritems(l)) { @@ -1623,6 +1623,9 @@ static int find_free_dev_extent_start(struct btrfs_device *device, if (key.type != BTRFS_DEV_EXTENT_KEY) goto next; + if (key.offset > search_end) + break; + if (key.offset > search_start) { hole_size = key.offset - search_start; dev_extent_hole_check(device, &search_start, &hole_size, @@ -1683,6 +1686,7 @@ static int find_free_dev_extent_start(struct btrfs_device *device, else ret = 0; + ASSERT(max_hole_start + max_hole_size <= search_end); out: btrfs_free_path(path); *start = max_hole_start; -- 2.26.3

2 years, 1 month

2
1
0 0

[PATCH 2/2] PCI/MSI: Validate device supplied MSI table offset and size

by Alexander Shishkin

Currently, the MSI table offset supplied by device's config space is passed directly into ioremap() without validation, allowing, for example, a malicious VMM to trick the OS into exposing its private memory. Correct this by making sure the table with the given number of vectors fits into its BIR starting at the provided table offset. Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Reported-by: Elena Reshetova <elena.reshetova(a)intel.com> Reviewed-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/pci/msi/msi.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c index d50cd45119f1..e93e633cb6a3 100644 --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -552,7 +552,8 @@ static void __iomem *msix_map_region(struct pci_dev *dev, unsigned int nr_entries) { resource_size_t phys_addr; - u32 table_offset; + u32 table_offset, table_size; + resource_size_t bir_size; unsigned long flags; u8 bir; @@ -563,10 +564,15 @@ static void __iomem *msix_map_region(struct pci_dev *dev, if (!flags || (flags & IORESOURCE_UNSET)) return NULL; + bir_size = pci_resource_len(dev, bir); + table_size = nr_entries * PCI_MSIX_ENTRY_SIZE; table_offset &= PCI_MSIX_TABLE_OFFSET; + if (bir_size < table_size || table_offset > bir_size - table_size) + return NULL; + phys_addr = pci_resource_start(dev, bir) + table_offset; - return ioremap(phys_addr, nr_entries * PCI_MSIX_ENTRY_SIZE); + return ioremap(phys_addr, table_size); } /** -- 2.39.0

2 years, 1 month

1
0
0 0

patch "comedi: adv_pci1760: Fix PWM instruction handling" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled comedi: adv_pci1760: Fix PWM instruction handling to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From 2efb6edd52dc50273f5e68ad863dd1b1fb2f2d1c Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Tue, 3 Jan 2023 14:37:54 +0000 Subject: comedi: adv_pci1760: Fix PWM instruction handling (Actually, this is fixing the "Read the Current Status" command sent to the device's outgoing mailbox, but it is only currently used for the PWM instructions.) The PCI-1760 is operated mostly by sending commands to a set of Outgoing Mailbox registers, waiting for the command to complete, and reading the result from the Incoming Mailbox registers. One of these commands is the "Read the Current Status" command. The number of this command is 0x07 (see the User's Manual for the PCI-1760 at <https://advdownload.advantech.com/productfile/Downloadfile2/1-11P6653/PCI-1…>. The `PCI1760_CMD_GET_STATUS` macro defined in the driver should expand to this command number 0x07, but unfortunately it currently expands to 0x03. (Command number 0x03 is not defined in the User's Manual.) Correct the definition of the `PCI1760_CMD_GET_STATUS` macro to fix it. This is used by all the PWM subdevice related instructions handled by `pci1760_pwm_insn_config()` which are probably all broken. The effect of sending the undefined command number 0x03 is not known. Fixes: 14b93bb6bbf0 ("staging: comedi: adv_pci_dio: separate out PCI-1760 support") Cc: <stable(a)vger.kernel.org> # v4.5+ Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Link: https://lore.kernel.org/r/20230103143754.17564-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/comedi/drivers/adv_pci1760.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/comedi/drivers/adv_pci1760.c b/drivers/comedi/drivers/adv_pci1760.c index fcfc2e299110..27f3890f471d 100644 --- a/drivers/comedi/drivers/adv_pci1760.c +++ b/drivers/comedi/drivers/adv_pci1760.c @@ -58,7 +58,7 @@ #define PCI1760_CMD_CLR_IMB2 0x00 /* Clears IMB2 */ #define PCI1760_CMD_SET_DO 0x01 /* Set output state */ #define PCI1760_CMD_GET_DO 0x02 /* Read output status */ -#define PCI1760_CMD_GET_STATUS 0x03 /* Read current status */ +#define PCI1760_CMD_GET_STATUS 0x07 /* Read current status */ #define PCI1760_CMD_GET_FW_VER 0x0e /* Read firmware version */ #define PCI1760_CMD_GET_HW_VER 0x0f /* Read hardware version */ #define PCI1760_CMD_SET_PWM_HI(x) (0x10 + (x) * 2) /* Set "hi" period */ -- 2.39.1

2 years, 1 month

1
0
0 0

[PATCH for 6.1 regression] mm, mremap: fix mremap() expanding for vma's with vm_ops->close()

by Vlastimil Babka

Fabian has reported another regression in 6.1 due to ca3d76b0aa80 ("mm: add merging after mremap resize"). The problem is that vma_merge() can fail when vma has a vm_ops->close() method, causing is_mergeable_vma() test to be negative. This was happening for vma mapping a file from fuse-overlayfs, which does have the method. But when we are simply expanding the vma, we never remove it due to the "merge" with the added area, so the test should not prevent the expansion. As a quick fix, check for such vmas and expand them using vma_adjust() directly as was done before commit ca3d76b0aa80. For a more robust long term solution we should try to limit the check for vma_ops->close only to cases that actually result in vma removal, so that no merge would be prevented unnecessarily. Reported-by: Fabian Vogt <fvogt(a)suse.com> Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359#c35 Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize") Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Jakub Matěna <matenajakub(a)gmail.com> Cc: <stable(a)vger.kernel.org> Tested-by: Fabian Vogt <fvogt(a)suse.com> --- Thorsten: this should be added to the previous regression which wasn't fully fixed by the previous patch: https://linux-regtracking.leemhuis.info/regzbot/regression/20221216163227.2… mm/mremap.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mremap.c b/mm/mremap.c index fe587c5d6591..1e234fd95547 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -1032,11 +1032,22 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, * the already existing vma (expand operation itself) and possibly also * with the next vma if it becomes adjacent to the expanded vma and * otherwise compatible. + * + * However, vma_merge() can currently fail due to is_mergeable_vma() + * check for vm_ops->close (see the comment there). Yet this should not + * prevent vma expanding, so perform a simple expand for such vma. + * Ideally the check for close op should be only done when a vma would + * be actually removed due to a merge. */ - vma = vma_merge(mm, vma, extension_start, extension_end, + if (!vma->vm_ops || !vma->vm_ops->close) { + vma = vma_merge(mm, vma, extension_start, extension_end, vma->vm_flags, vma->anon_vma, vma->vm_file, extension_pgoff, vma_policy(vma), vma->vm_userfaultfd_ctx, anon_vma_name(vma)); + } else if (vma_adjust(vma, vma->vm_start, addr + new_len, + vma->vm_pgoff, NULL)) { + vma = NULL; + } if (!vma) { vm_unacct_memory(pages); ret = -ENOMEM; -- 2.38.1

2 years, 1 month

2
2
0 0

patch "tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From b8caf69a6946e18ffebad49847e258f5b6d52ac2 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Date: Wed, 21 Dec 2022 17:40:22 +0100 Subject: tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. Fixes: f9d690b6ece7 ("tty: serial: qcom_geni_serial: Allocate port->rx_fifo buffer in probe") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Reviewed-by: Jiri Slaby <jirislaby(a)kernel.org> Link: https://lore.kernel.org/r/20221221164022.1087814-1-krzysztof.kozlowski@lina… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/qcom_geni_serial.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c index b487823f0e61..49b9ffeae676 100644 --- a/drivers/tty/serial/qcom_geni_serial.c +++ b/drivers/tty/serial/qcom_geni_serial.c @@ -864,9 +864,10 @@ static irqreturn_t qcom_geni_serial_isr(int isr, void *dev) return IRQ_HANDLED; } -static void get_tx_fifo_size(struct qcom_geni_serial_port *port) +static int setup_fifos(struct qcom_geni_serial_port *port) { struct uart_port *uport; + u32 old_rx_fifo_depth = port->rx_fifo_depth; uport = &port->uport; port->tx_fifo_depth = geni_se_get_tx_fifo_depth(&port->se); @@ -874,6 +875,16 @@ static void get_tx_fifo_size(struct qcom_geni_serial_port *port) port->rx_fifo_depth = geni_se_get_rx_fifo_depth(&port->se); uport->fifosize = (port->tx_fifo_depth * port->tx_fifo_width) / BITS_PER_BYTE; + + if (port->rx_fifo && (old_rx_fifo_depth != port->rx_fifo_depth) && port->rx_fifo_depth) { + port->rx_fifo = devm_krealloc(uport->dev, port->rx_fifo, + port->rx_fifo_depth * sizeof(u32), + GFP_KERNEL); + if (!port->rx_fifo) + return -ENOMEM; + } + + return 0; } @@ -888,6 +899,7 @@ static int qcom_geni_serial_port_setup(struct uart_port *uport) u32 rxstale = DEFAULT_BITS_PER_CHAR * STALE_TIMEOUT; u32 proto; u32 pin_swap; + int ret; proto = geni_se_read_proto(&port->se); if (proto != GENI_SE_UART) { @@ -897,7 +909,9 @@ static int qcom_geni_serial_port_setup(struct uart_port *uport) qcom_geni_serial_stop_rx(uport); - get_tx_fifo_size(port); + ret = setup_fifos(port); + if (ret) + return ret; writel(rxstale, uport->membase + SE_UART_RX_STALE_CNT); -- 2.39.1

2 years, 1 month

1
0
0 0

Re: [PATCH] clocksource/drivers/arm_arch_timer: Update sched_clock when non-boot CPUs need counter workaround

by 王法杰

Hi Marc Zyngier We found the APPS Crash issue on MTBF test. Brief crash information, APPS Crash - Kernel BUG at /sched/walt/sched_avg.c:281! in sched_update_nr_prod flow [Test equipment] 1. Number of phone: 200 pcs 2. CPU info of phone: CPU architecture with Quad Cortex-A73 and Quad Cortex-A53 [Preset conditions] 1. Android 13 with kernel 5.15 2. Install application of top 20 3. Connected to Wi-Fi 4. Connect the adapter to charge the phone 5. Test duration 48 hours [Expected results] 0 crash happened. [Test results without [PATCH] clocksource/drivers/arm_arch_timer: Update sched_clock when non-boot CPUs need counter workaround ] 1. First round of test, found 3 phones with APPS Crash issue on /sched/walt/sched_avg.c:281! in sched_update_nr_prod flow 2. Second round of test, found 7 phones with APP Crash issue on /sched/walt/sched_avg.c:281! in sched_update_nr_prod flow [Test results with [PATCH] clocksource/drivers/arm_arch_timer: Update sched_clock when non-boot CPUs need counter workaround ] 1. First round of test, 0 crash happened. 2. Second round of test, 0 crash happened. Tested-by: wangfajie <wangfajie(a)longcheer.com> Tested-by: liurenwang <liurenwang(a)longcheer.com> Tested-by: zhanghui <zhanghui5(a)longcheer.com> Tested-by: liangke <liangke1(a)xiaomi.com> So we think the PATCH is working and it can fix APPS crash issue. Many thanks your time. Best regards! Wangfajie -----邮件原件----- 发件人: Marc Zyngier [mailto:maz@kernel.org] 发送时间: 2023年1月19日 17:52 收件人: 刘琦 <liuqi405(a)icloud.com> 抄送: daniel.lezcano(a)kernel.org; linux-arm-kernel(a)lists.infradead.org; linux-kernel(a)vger.kernel.org; mark.rutland(a)arm.com; quic_ylal(a)quicinc.com; stable(a)vger.kernel.org; will(a)kernel.org; 王法杰 <wangfajie(a)longcheer.com>; 刘仁旺 <liurenwang(a)longcheer.com>; 张辉 <zhanghui5(a)longcheer.com>; liangke1(a)xiaomi.com 主题: Re: [PATCH] clocksource/drivers/arm_arch_timer: Update sched_clock when non-boot CPUs need counter workaround On 2023-01-19 07:59, 刘琦 wrote: > [Test Report] > Result: Test Pass > > A total of two rounds of pending testing > a. The first round of hanging test > Number of machines: 200 > Hanging test duration: 48h > Hanging test results: no walt crash problem > b. The second round of hanging test > Number of machines: 200 > Hanging test duration: 72h > Hanging test results: no walt crash problem > > Tested-by: wangfajie <wangfajie(a)longcheer.com> > Tested-by: liurenwang <liurenwang(a)longcheer.com> > Tested-by: zhanghui <zhanghui5(a)longcheer.com> > Tested-by: liangke <liangke1(a)xiaomi.com> Thanks for this. The only issue here is that that you don't explain what you tested, nor how you tested it. It is also a patch that has known defects (you just have to read the thread for the details)... This makes this testing, no matter how thorough it is, rather ineffective. M. -- Jazz is not dead. It just smells funny...

2 years, 1 month

1
0
0 0

[PATCH 5.10 0/1] drm/amdkfd: Check for null pointer after calling kmemdup

by Dragos-Marian Panait

The following commit is needed to fix CVE-2022-3108: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Jiasheng Jiang (1): drm/amdkfd: Check for null pointer after calling kmemdup drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 3 +++ 1 file changed, 3 insertions(+) base-commit: 0fe4548663f7dc2c3b549ef54ce9bb6d40a235be -- 2.38.1

2 years, 1 month

4
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2023