August 2025 - Linux-stable-mirror

by Alan Ye

The Qualcomm SM6375 processor is a 7nm process SoC for the mid-range market with the following features: CPU: Eight-core design, including high-performance Kryo 670 core and efficient Kryo 265 core, optimized performance and energy efficiency. GPU: Equipped with Adreno 642L GPU, supporting high-quality graphics and gaming experience. AI Engine: Integrated Qualcomm AI engine to enhance intelligent features such as voice recognition and image processing. Connectivity: Supports modern wireless standards such as 5G, Wi-Fi 6 and Bluetooth 5.2. Multimedia: Supports 4K video encoding and decoding Mainly used in mid-to-high-end smartphones, tablets and some IoT devices, suitable for users who need to balance cost performance and performance. .# Part Number Manufacturer Date Code Quantity Unit Price Lead Time Condition (PCS) USD/Each one 1 SM-6375-1-PSP837-TR-00-0-AB QUALCOMM 2023+ 12000pcs US$18.00/pcs 7days New & original - stock 2 PM-6375-0-FOWNSP144-TR-01-0；TR-01-1 QUALCOMM 2023+ 12000pcs US$1.00/pcs 3 PMR-735A-0-WLNSP48-TR-05-0,TR-05-1 QUALCOMM 2023+ 12000pcs US$0.85/pcs 4 PMK-8003-0-FOWPSP36-TR-01-0 QUALCOMM 2023+ 12000pcs US$0.24/pcs 5 SDR-735-0-PSP219B-TR-01-0；TR-01-1 QUALCOMM 2023+ 12000pcs US$2.50/pcs 6 WCD-9370-0-WLPSP55-TR-01-0;TR-01-4 QUALCOMM 2023+ 12000pcs US$0.50/pcs 7 WCN-3988-0-82BWLPSP-TR-00-0 QUALCOMM 2023+ 12000pcs US$3.50/pcs 8 QET-6105-0-WLNSP24B-TR-00-1 QUALCOMM 2023+ 12000pcs US$1.20/pcs 9 QET4101-0-12WLNSP-TR-00-0 QUALCOMM 2022+ 12000pcs US$0.21/pcs These materials are sold as a set for $28/usd, and are guaranteed to be authentic. If you need other Qualcomm materials, please feel free to contact me Stay in tune with product evolutions—tap . Keep Receiving Notices Feel like taking a break? Select Configure Your Mailing.

1 month

1
0
0 0

[PATCH v2] usb: renesas-xhci: Fix External ROM access timeouts

by Marek Vasut

Increase the External ROM access timeouts to prevent failures during programming of External SPI EEPROM chips. The current timeouts are too short for some SPI EEPROMs used with uPD720201 controllers. The current timeout for Chip Erase in renesas_rom_erase() is 100 ms , the current timeout for Sector Erase issued by the controller before Page Program in renesas_fw_download_image() is also 100 ms. Neither timeout is sufficient for e.g. the Macronix MX25L5121E or MX25V5126F. MX25L5121E reference manual [1] page 35 section "ERASE AND PROGRAMMING PERFORMANCE" and page 23 section "Table 8. AC CHARACTERISTICS (Temperature = 0°C to 70°C for Commercial grade, VCC = 2.7V ~ 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 2 s, and for Sector Erase it is 300 ms . MX25V5126F reference manual [2] page 47 section "13. ERASE AND PROGRAMMING PERFORMANCE (2.3V - 3.6V)" and page 42 section "Table 8. AC CHARACTERISTICS (Temperature = -40°C to 85°C for Industrial grade, VCC = 2.3V - 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 3.2 s, and for Sector Erase it is 400 ms . Update the timeouts such, that Chip Erase timeout is set to 5 seconds, and Sector Erase timeout is set to 500 ms. Such lengthy timeouts ought to be sufficient for majority of SPI EEPROM chips. [1] https://www.macronix.com/Lists/Datasheet/Attachments/8634/MX25L5121E,%203V,… [2] https://www.macronix.com/Lists/Datasheet/Attachments/8750/MX25V5126F,%202.5… Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Cc: <stable(a)vger.kernel.org> Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: Geert Uytterhoeven <geert+renesas(a)glider.be> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Mathias Nyman <mathias.nyman(a)intel.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: linux-renesas-soc(a)vger.kernel.org Cc: linux-usb(a)vger.kernel.org --- V2: Move Cc: stable above --- --- drivers/usb/host/xhci-pci-renesas.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-pci-renesas.c b/drivers/usb/host/xhci-pci-renesas.c index 620f8f0febb8..86df80399c9f 100644 --- a/drivers/usb/host/xhci-pci-renesas.c +++ b/drivers/usb/host/xhci-pci-renesas.c @@ -47,8 +47,9 @@ #define RENESAS_ROM_ERASE_MAGIC 0x5A65726F #define RENESAS_ROM_WRITE_MAGIC 0x53524F4D -#define RENESAS_RETRY 10000 -#define RENESAS_DELAY 10 +#define RENESAS_RETRY 50000 /* 50000 * RENESAS_DELAY ~= 500ms */ +#define RENESAS_CHIP_ERASE_RETRY 500000 /* 500000 * RENESAS_DELAY ~= 5s */ +#define RENESAS_DELAY 10 #define RENESAS_FW_NAME "renesas_usb_fw.mem" @@ -407,7 +408,7 @@ static void renesas_rom_erase(struct pci_dev *pdev) /* sleep a bit while ROM is erased */ msleep(20); - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < RENESAS_CHIP_ERASE_RETRY; i++) { retval = pci_read_config_byte(pdev, RENESAS_ROM_STATUS, &status); status &= RENESAS_ROM_STATUS_ERASE; -- 2.47.2

1 month

1
0
0 0

[PATCH] usb: renesas-xhci: Fix External ROM access timeouts

by Marek Vasut

Increase the External ROM access timeouts to prevent failures during programming of External SPI EEPROM chips. The current timeouts are too short for some SPI EEPROMs used with uPD720201 controllers. The current timeout for Chip Erase in renesas_rom_erase() is 100 ms , the current timeout for Sector Erase issued by the controller before Page Program in renesas_fw_download_image() is also 100 ms. Neither timeout is sufficient for e.g. the Macronix MX25L5121E or MX25V5126F. MX25L5121E reference manual [1] page 35 section "ERASE AND PROGRAMMING PERFORMANCE" and page 23 section "Table 8. AC CHARACTERISTICS (Temperature = 0°C to 70°C for Commercial grade, VCC = 2.7V ~ 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 2 s, and for Sector Erase it is 300 ms . MX25V5126F reference manual [2] page 47 section "13. ERASE AND PROGRAMMING PERFORMANCE (2.3V - 3.6V)" and page 42 section "Table 8. AC CHARACTERISTICS (Temperature = -40°C to 85°C for Industrial grade, VCC = 2.3V - 3.6V)" row "tCE" indicate that the maximum time required for Chip Erase opcode to complete is 3.2 s, and for Sector Erase it is 400 ms . Update the timeouts such, that Chip Erase timeout is set to 5 seconds, and Sector Erase timeout is set to 500 ms. Such lengthy timeouts ought to be sufficient for majority of SPI EEPROM chips. [1] https://www.macronix.com/Lists/Datasheet/Attachments/8634/MX25L5121E,%203V,… [2] https://www.macronix.com/Lists/Datasheet/Attachments/8750/MX25V5126F,%202.5… Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: Geert Uytterhoeven <geert+renesas(a)glider.be> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Mathias Nyman <mathias.nyman(a)intel.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: <stable(a)vger.kernel.org> Cc: linux-renesas-soc(a)vger.kernel.org Cc: linux-usb(a)vger.kernel.org --- drivers/usb/host/xhci-pci-renesas.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-pci-renesas.c b/drivers/usb/host/xhci-pci-renesas.c index 620f8f0febb8..86df80399c9f 100644 --- a/drivers/usb/host/xhci-pci-renesas.c +++ b/drivers/usb/host/xhci-pci-renesas.c @@ -47,8 +47,9 @@ #define RENESAS_ROM_ERASE_MAGIC 0x5A65726F #define RENESAS_ROM_WRITE_MAGIC 0x53524F4D -#define RENESAS_RETRY 10000 -#define RENESAS_DELAY 10 +#define RENESAS_RETRY 50000 /* 50000 * RENESAS_DELAY ~= 500ms */ +#define RENESAS_CHIP_ERASE_RETRY 500000 /* 500000 * RENESAS_DELAY ~= 5s */ +#define RENESAS_DELAY 10 #define RENESAS_FW_NAME "renesas_usb_fw.mem" @@ -407,7 +408,7 @@ static void renesas_rom_erase(struct pci_dev *pdev) /* sleep a bit while ROM is erased */ msleep(20); - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < RENESAS_CHIP_ERASE_RETRY; i++) { retval = pci_read_config_byte(pdev, RENESAS_ROM_STATUS, &status); status &= RENESAS_ROM_STATUS_ERASE; -- 2.47.2

1 month

6
9
0 0

[PATCH v2] kcov, usb: Fix invalid context sleep in softirq path on PREEMPT_RT

by Yunseong Kim

The KCOV subsystem currently utilizes standard spinlock_t and local_lock_t for synchronization. In PREEMPT_RT configurations, these locks can be implemented via rtmutexes and may therefore sleep. This behavior is problematic as kcov locks are sometimes used in atomic contexts or protect data accessed during critical instrumentation paths where sleeping is not permissible. Address these issues to make kcov PREEMPT_RT friendly: 1. Convert kcov->lock and kcov_remote_lock from spinlock_t to raw_spinlock_t. This ensures they remain true, non-sleeping spinlocks even on PREEMPT_RT kernels. 2. Refactor the KCOV_REMOTE_ENABLE path to move memory allocations out of the critical section. All necessary struct kcov_remote structures are now pre-allocated individually in kcov_ioctl() using GFP_KERNEL (allowing sleep) before acquiring the raw spinlocks. 3. Modify the ioctl handling logic to utilize these pre-allocated structures within the critical section. kcov_remote_add() is modified to accept a pre-allocated structure instead of allocating one internally. 4. Remove the local_lock_t protection for kcov_percpu_data in kcov_remote_start/stop(). Since local_lock_t can also sleep under RT, and the required protection is against local interrupts when accessing per-CPU data, it is replaced with explicit local_irq_save/restore(). Link: https://lore.kernel.org/all/20250725201400.1078395-2-ysk@kzalloc.com/t/#u Fixes: f85d39dd7ed8 ("kcov, usb: disable interrupts in kcov_remote_start_usb_softirq") Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp> Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: Byungchul Park <byungchul(a)sk.com> Cc: stable(a)vger.kernel.org Cc: kasan-dev(a)googlegroups.com Cc: syzkaller(a)googlegroups.com Cc: linux-usb(a)vger.kernel.org Cc: linux-rt-devel(a)lists.linux.dev Signed-off-by: Yunseong Kim <ysk(a)kzalloc.com> --- kernel/kcov.c | 243 +++++++++++++++++++++++++++----------------------- 1 file changed, 130 insertions(+), 113 deletions(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index 187ba1b80bda..9c8e4325cff8 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -54,7 +54,7 @@ struct kcov { */ refcount_t refcount; /* The lock protects mode, size, area and t. */ - spinlock_t lock; + raw_spinlock_t lock; enum kcov_mode mode; /* Size of arena (in long's). */ unsigned int size; @@ -84,13 +84,12 @@ struct kcov_remote { struct hlist_node hnode; }; -static DEFINE_SPINLOCK(kcov_remote_lock); +static DEFINE_RAW_SPINLOCK(kcov_remote_lock); static DEFINE_HASHTABLE(kcov_remote_map, 4); static struct list_head kcov_remote_areas = LIST_HEAD_INIT(kcov_remote_areas); struct kcov_percpu_data { void *irq_area; - local_lock_t lock; unsigned int saved_mode; unsigned int saved_size; @@ -99,9 +98,7 @@ struct kcov_percpu_data { int saved_sequence; }; -static DEFINE_PER_CPU(struct kcov_percpu_data, kcov_percpu_data) = { - .lock = INIT_LOCAL_LOCK(lock), -}; +static DEFINE_PER_CPU(struct kcov_percpu_data, kcov_percpu_data); /* Must be called with kcov_remote_lock locked. */ static struct kcov_remote *kcov_remote_find(u64 handle) @@ -116,15 +113,9 @@ static struct kcov_remote *kcov_remote_find(u64 handle) } /* Must be called with kcov_remote_lock locked. */ -static struct kcov_remote *kcov_remote_add(struct kcov *kcov, u64 handle) +static struct kcov_remote *kcov_remote_add(struct kcov *kcov, u64 handle, + struct kcov_remote *remote) { - struct kcov_remote *remote; - - if (kcov_remote_find(handle)) - return ERR_PTR(-EEXIST); - remote = kmalloc(sizeof(*remote), GFP_ATOMIC); - if (!remote) - return ERR_PTR(-ENOMEM); remote->handle = handle; remote->kcov = kcov; hash_add(kcov_remote_map, &remote->hnode, handle); @@ -404,9 +395,8 @@ static void kcov_remote_reset(struct kcov *kcov) int bkt; struct kcov_remote *remote; struct hlist_node *tmp; - unsigned long flags; - spin_lock_irqsave(&kcov_remote_lock, flags); + raw_spin_lock(&kcov_remote_lock); hash_for_each_safe(kcov_remote_map, bkt, tmp, remote, hnode) { if (remote->kcov != kcov) continue; @@ -415,7 +405,7 @@ static void kcov_remote_reset(struct kcov *kcov) } /* Do reset before unlock to prevent races with kcov_remote_start(). */ kcov_reset(kcov); - spin_unlock_irqrestore(&kcov_remote_lock, flags); + raw_spin_unlock(&kcov_remote_lock); } static void kcov_disable(struct task_struct *t, struct kcov *kcov) @@ -450,7 +440,7 @@ void kcov_task_exit(struct task_struct *t) if (kcov == NULL) return; - spin_lock_irqsave(&kcov->lock, flags); + raw_spin_lock_irqsave(&kcov->lock, flags); kcov_debug("t = %px, kcov->t = %px\n", t, kcov->t); /* * For KCOV_ENABLE devices we want to make sure that t->kcov->t == t, @@ -475,12 +465,12 @@ void kcov_task_exit(struct task_struct *t) * By combining all three checks into one we get: */ if (WARN_ON(kcov->t != t)) { - spin_unlock_irqrestore(&kcov->lock, flags); + raw_spin_unlock_irqrestore(&kcov->lock, flags); return; } /* Just to not leave dangling references behind. */ kcov_disable(t, kcov); - spin_unlock_irqrestore(&kcov->lock, flags); + raw_spin_unlock_irqrestore(&kcov->lock, flags); kcov_put(kcov); } @@ -492,14 +482,14 @@ static int kcov_mmap(struct file *filep, struct vm_area_struct *vma) struct page *page; unsigned long flags; - spin_lock_irqsave(&kcov->lock, flags); + raw_spin_lock_irqsave(&kcov->lock, flags); size = kcov->size * sizeof(unsigned long); if (kcov->area == NULL || vma->vm_pgoff != 0 || vma->vm_end - vma->vm_start != size) { res = -EINVAL; goto exit; } - spin_unlock_irqrestore(&kcov->lock, flags); + raw_spin_unlock_irqrestore(&kcov->lock, flags); vm_flags_set(vma, VM_DONTEXPAND); for (off = 0; off < size; off += PAGE_SIZE) { page = vmalloc_to_page(kcov->area + off); @@ -511,7 +501,7 @@ static int kcov_mmap(struct file *filep, struct vm_area_struct *vma) } return 0; exit: - spin_unlock_irqrestore(&kcov->lock, flags); + raw_spin_unlock_irqrestore(&kcov->lock, flags); return res; } @@ -525,7 +515,7 @@ static int kcov_open(struct inode *inode, struct file *filep) kcov->mode = KCOV_MODE_DISABLED; kcov->sequence = 1; refcount_set(&kcov->refcount, 1); - spin_lock_init(&kcov->lock); + raw_spin_lock_init(&kcov->lock); filep->private_data = kcov; return nonseekable_open(inode, filep); } @@ -586,10 +576,8 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, unsigned long arg) { struct task_struct *t; - unsigned long flags, unused; - int mode, i; - struct kcov_remote_arg *remote_arg; - struct kcov_remote *remote; + unsigned long unused; + int mode; switch (cmd) { case KCOV_ENABLE: @@ -627,69 +615,80 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, kcov_disable(t, kcov); kcov_put(kcov); return 0; - case KCOV_REMOTE_ENABLE: - if (kcov->mode != KCOV_MODE_INIT || !kcov->area) - return -EINVAL; - t = current; - if (kcov->t != NULL || t->kcov != NULL) - return -EBUSY; - remote_arg = (struct kcov_remote_arg *)arg; - mode = kcov_get_mode(remote_arg->trace_mode); - if (mode < 0) - return mode; - if ((unsigned long)remote_arg->area_size > - LONG_MAX / sizeof(unsigned long)) - return -EINVAL; - kcov->mode = mode; - t->kcov = kcov; - t->kcov_mode = KCOV_MODE_REMOTE; - kcov->t = t; - kcov->remote = true; - kcov->remote_size = remote_arg->area_size; - spin_lock_irqsave(&kcov_remote_lock, flags); - for (i = 0; i < remote_arg->num_handles; i++) { - if (!kcov_check_handle(remote_arg->handles[i], - false, true, false)) { - spin_unlock_irqrestore(&kcov_remote_lock, - flags); - kcov_disable(t, kcov); - return -EINVAL; - } - remote = kcov_remote_add(kcov, remote_arg->handles[i]); - if (IS_ERR(remote)) { - spin_unlock_irqrestore(&kcov_remote_lock, - flags); - kcov_disable(t, kcov); - return PTR_ERR(remote); - } - } - if (remote_arg->common_handle) { - if (!kcov_check_handle(remote_arg->common_handle, - true, false, false)) { - spin_unlock_irqrestore(&kcov_remote_lock, - flags); - kcov_disable(t, kcov); - return -EINVAL; - } - remote = kcov_remote_add(kcov, - remote_arg->common_handle); - if (IS_ERR(remote)) { - spin_unlock_irqrestore(&kcov_remote_lock, - flags); - kcov_disable(t, kcov); - return PTR_ERR(remote); - } - t->kcov_handle = remote_arg->common_handle; - } - spin_unlock_irqrestore(&kcov_remote_lock, flags); - /* Put either in kcov_task_exit() or in KCOV_DISABLE. */ - kcov_get(kcov); - return 0; default: return -ENOTTY; } } +static int kcov_ioctl_locked_remote_enabled(struct kcov *kcov, + unsigned int cmd, unsigned long arg, + struct kcov_remote *remote_handles, + struct kcov_remote *remote_common_handle) +{ + struct task_struct *t; + int mode, i, ret; + struct kcov_remote_arg *remote_arg; + + if (kcov->mode != KCOV_MODE_INIT || !kcov->area) + return -EINVAL; + t = current; + if (kcov->t != NULL || t->kcov != NULL) + return -EBUSY; + remote_arg = (struct kcov_remote_arg *)arg; + mode = kcov_get_mode(remote_arg->trace_mode); + if (mode < 0) + return mode; + if ((unsigned long)remote_arg->area_size > + LONG_MAX / sizeof(unsigned long)) + return -EINVAL; + kcov->mode = mode; + t->kcov = kcov; + t->kcov_mode = KCOV_MODE_REMOTE; + kcov->t = t; + kcov->remote = true; + kcov->remote_size = remote_arg->area_size; + raw_spin_lock(&kcov_remote_lock); + for (i = 0; i < remote_arg->num_handles; i++) { + if (!kcov_check_handle(remote_arg->handles[i], + false, true, false)) { + ret = -EINVAL; + goto err; + } + if (kcov_remote_find(remote_arg->handles[i])) { + ret = -EEXIST; + goto err; + } + kcov_remote_add(kcov, remote_arg->handles[i], + &remote_handles[i]); + } + if (remote_arg->common_handle) { + if (!kcov_check_handle(remote_arg->common_handle, + true, false, false)) { + ret = -EINVAL; + goto err; + } + if (kcov_remote_find(remote_arg->common_handle)) { + ret = -EEXIST; + goto err; + } + kcov_remote_add(kcov, + remote_arg->common_handle, remote_common_handle); + t->kcov_handle = remote_arg->common_handle; + } + raw_spin_unlock(&kcov_remote_lock); + /* Put either in kcov_task_exit() or in KCOV_DISABLE. */ + kcov_get(kcov); + return 0; + +err: + raw_spin_unlock(&kcov_remote_lock); + kcov_disable(t, kcov); + kfree(remote_common_handle); + kfree(remote_handles); + + return ret; +} + static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) { struct kcov *kcov; @@ -697,6 +696,7 @@ static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) struct kcov_remote_arg *remote_arg = NULL; unsigned int remote_num_handles; unsigned long remote_arg_size; + struct kcov_remote *remote_handles, *remote_common_handle; unsigned long size, flags; void *area; @@ -716,16 +716,16 @@ static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) area = vmalloc_user(size * sizeof(unsigned long)); if (area == NULL) return -ENOMEM; - spin_lock_irqsave(&kcov->lock, flags); + raw_spin_lock_irqsave(&kcov->lock, flags); if (kcov->mode != KCOV_MODE_DISABLED) { - spin_unlock_irqrestore(&kcov->lock, flags); + raw_spin_unlock_irqrestore(&kcov->lock, flags); vfree(area); return -EBUSY; } kcov->area = area; kcov->size = size; kcov->mode = KCOV_MODE_INIT; - spin_unlock_irqrestore(&kcov->lock, flags); + raw_spin_unlock_irqrestore(&kcov->lock, flags); return 0; case KCOV_REMOTE_ENABLE: if (get_user(remote_num_handles, (unsigned __user *)(arg + @@ -743,18 +743,35 @@ static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) return -EINVAL; } arg = (unsigned long)remote_arg; - fallthrough; + remote_handles = kmalloc_array(remote_arg->num_handles, + sizeof(struct kcov_remote), GFP_KERNEL); + if (!remote_handles) + return -ENOMEM; + remote_common_handle = kmalloc(sizeof(struct kcov_remote), GFP_KERNEL); + if (!remote_common_handle) { + kfree(remote_handles); + return -ENOMEM; + } + + raw_spin_lock_irqsave(&kcov->lock, flags); + res = kcov_ioctl_locked_remote_enabled(kcov, cmd, arg, + remote_handles, remote_common_handle); + raw_spin_unlock_irqrestore(&kcov->lock, flags); + kfree(remote_arg); + break; default: /* + * KCOV_ENABLE, KCOV_DISABLE: * All other commands can be normally executed under a spin lock, so we * obtain and release it here in order to simplify kcov_ioctl_locked(). */ - spin_lock_irqsave(&kcov->lock, flags); + raw_spin_lock_irqsave(&kcov->lock, flags); res = kcov_ioctl_locked(kcov, cmd, arg); - spin_unlock_irqrestore(&kcov->lock, flags); - kfree(remote_arg); - return res; + raw_spin_unlock_irqrestore(&kcov->lock, flags); + break; } + + return res; } static const struct file_operations kcov_fops = { @@ -862,7 +879,7 @@ void kcov_remote_start(u64 handle) if (!in_task() && !in_softirq_really()) return; - local_lock_irqsave(&kcov_percpu_data.lock, flags); + local_irq_save(flags); /* * Check that kcov_remote_start() is not called twice in background @@ -870,7 +887,7 @@ void kcov_remote_start(u64 handle) */ mode = READ_ONCE(t->kcov_mode); if (WARN_ON(in_task() && kcov_mode_enabled(mode))) { - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); return; } /* @@ -879,15 +896,15 @@ void kcov_remote_start(u64 handle) * happened while collecting coverage from a background thread. */ if (WARN_ON(in_serving_softirq() && t->kcov_softirq)) { - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); return; } - spin_lock(&kcov_remote_lock); + raw_spin_lock(&kcov_remote_lock); remote = kcov_remote_find(handle); if (!remote) { - spin_unlock(&kcov_remote_lock); - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + raw_spin_unlock(&kcov_remote_lock); + local_irq_restore(flags); return; } kcov_debug("handle = %llx, context: %s\n", handle, @@ -908,17 +925,17 @@ void kcov_remote_start(u64 handle) size = CONFIG_KCOV_IRQ_AREA_SIZE; area = this_cpu_ptr(&kcov_percpu_data)->irq_area; } - spin_unlock(&kcov_remote_lock); + raw_spin_unlock(&kcov_remote_lock); /* Can only happen when in_task(). */ if (!area) { - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); area = vmalloc(size * sizeof(unsigned long)); if (!area) { kcov_put(kcov); return; } - local_lock_irqsave(&kcov_percpu_data.lock, flags); + local_irq_save(flags); } /* Reset coverage size. */ @@ -930,7 +947,7 @@ void kcov_remote_start(u64 handle) } kcov_start(t, kcov, size, area, mode, sequence); - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); } EXPORT_SYMBOL(kcov_remote_start); @@ -1004,12 +1021,12 @@ void kcov_remote_stop(void) if (!in_task() && !in_softirq_really()) return; - local_lock_irqsave(&kcov_percpu_data.lock, flags); + local_irq_save(flags); mode = READ_ONCE(t->kcov_mode); barrier(); if (!kcov_mode_enabled(mode)) { - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); return; } /* @@ -1017,12 +1034,12 @@ void kcov_remote_stop(void) * actually found the remote handle and started collecting coverage. */ if (in_serving_softirq() && !t->kcov_softirq) { - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); return; } /* Make sure that kcov_softirq is only set when in softirq. */ if (WARN_ON(!in_serving_softirq() && t->kcov_softirq)) { - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); return; } @@ -1037,22 +1054,22 @@ void kcov_remote_stop(void) kcov_remote_softirq_stop(t); } - spin_lock(&kcov->lock); + raw_spin_lock(&kcov->lock); /* * KCOV_DISABLE could have been called between kcov_remote_start() * and kcov_remote_stop(), hence the sequence check. */ if (sequence == kcov->sequence && kcov->remote) kcov_move_area(kcov->mode, kcov->area, kcov->size, area); - spin_unlock(&kcov->lock); + raw_spin_unlock(&kcov->lock); if (in_task()) { - spin_lock(&kcov_remote_lock); + raw_spin_lock(&kcov_remote_lock); kcov_remote_area_put(area, size); - spin_unlock(&kcov_remote_lock); + raw_spin_unlock(&kcov_remote_lock); } - local_unlock_irqrestore(&kcov_percpu_data.lock, flags); + local_irq_restore(flags); /* Get in kcov_remote_start(). */ kcov_put(kcov); -- 2.50.0

1 month

2
3
0 0

Text mode VGA-console scrolling is broken in upstream & stable trees

by Jari Ruusu

The patch that broke text mode VGA-console scrolling is this one: "vgacon: Add check for vc_origin address range in vgacon_scroll()" commit 864f9963ec6b4b76d104d595ba28110b87158003 upstream. How to preproduce: (1) boot a kernel that is configured to use text mode VGA-console (2) type commands: ls -l /usr/bin | less -S (3) scroll up/down with cursor-down/up keys Above mentioned patch seems to have landed in upstream and all kernel.org stable trees with zero testing. Even minimal testing would have shown that it breaks text mode VGA-console scrolling. Greg, Sasha, Linus, Please consider reverting that buggy patch from all affected trees. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189

1 month

5
5
0 0

[merged mm-stable] mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped has been removed from the -mm tree. Its filename was mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Suren Baghdasaryan <surenb(a)google.com> Subject: mm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped Date: Mon, 28 Jul 2025 10:53:55 -0700 By inducing delays in the right places, Jann Horn created a reproducer for a hard to hit UAF issue that became possible after VMAs were allowed to be recycled by adding SLAB_TYPESAFE_BY_RCU to their cache. Race description is borrowed from Jann's discovery report: lock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under rcu_read_lock(). At that point, the VMA may be concurrently freed, and it can be recycled by another process. vma_start_read() then increments the vma->vm_refcnt (if it is in an acceptable range), and if this succeeds, vma_start_read() can return a recycled VMA. In this scenario where the VMA has been recycled, lock_vma_under_rcu() will then detect the mismatching ->vm_mm pointer and drop the VMA through vma_end_read(), which calls vma_refcount_put(). vma_refcount_put() drops the refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. This is wrong: It implicitly assumes that the caller is keeping the VMA's mm alive, but in this scenario the caller has no relation to the VMA's mm, so the rcuwait_wake_up() can cause UAF. The diagram depicting the race: T1 T2 T3 == == == lock_vma_under_rcu mas_walk <VMA gets removed from mm> mmap <the same VMA is reallocated> vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event <finish operation> rcuwait_wake_up [UAF] Note that rcuwait_wait_event() in T3 does not block because refcount was already dropped by T1. At this point T3 can exit and free the mm causing UAF in T1. To avoid this we move vma->vm_mm verification into vma_start_read() and grab vma->vm_mm to stabilize it before vma_refcount_put() operation. [surenb(a)google.com: v3] Link: https://lkml.kernel.org/r/20250729145709.2731370-1-surenb@google.com Link: https://lkml.kernel.org/r/20250728175355.2282375-1-surenb@google.com Fixes: 3104138517fc ("mm: make vma cache SLAB_TYPESAFE_BY_RCU") Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Reported-by: Jann Horn <jannh(a)google.com> Closes: https://lore.kernel.org/all/CAG48ez0-deFbVH=E3jbkWx=X3uVbd8nWeo6kbJPQ0KoUD+… Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Acked-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Jann Horn <jannh(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mmap_lock.h | 30 ++++++++++++++++++++++++++++++ mm/mmap_lock.c | 10 +++------- 2 files changed, 33 insertions(+), 7 deletions(-) --- a/include/linux/mmap_lock.h~mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped +++ a/include/linux/mmap_lock.h @@ -12,6 +12,7 @@ extern int rcuwait_wake_up(struct rcuwai #include <linux/tracepoint-defs.h> #include <linux/types.h> #include <linux/cleanup.h> +#include <linux/sched/mm.h> #define MMAP_LOCK_INITIALIZER(name) \ .mmap_lock = __RWSEM_INITIALIZER((name).mmap_lock), @@ -154,6 +155,10 @@ static inline void vma_refcount_put(stru * reused and attached to a different mm before we lock it. * Returns the vma on success, NULL on failure to lock and EAGAIN if vma got * detached. + * + * WARNING! The vma passed to this function cannot be used if the function + * fails to lock it because in certain cases RCU lock is dropped and then + * reacquired. Once RCU lock is dropped the vma can be concurently freed. */ static inline struct vm_area_struct *vma_start_read(struct mm_struct *mm, struct vm_area_struct *vma) @@ -183,6 +188,31 @@ static inline struct vm_area_struct *vma } rwsem_acquire_read(&vma->vmlock_dep_map, 0, 1, _RET_IP_); + + /* + * If vma got attached to another mm from under us, that mm is not + * stable and can be freed in the narrow window after vma->vm_refcnt + * is dropped and before rcuwait_wake_up(mm) is called. Grab it before + * releasing vma->vm_refcnt. + */ + if (unlikely(vma->vm_mm != mm)) { + /* Use a copy of vm_mm in case vma is freed after we drop vm_refcnt */ + struct mm_struct *other_mm = vma->vm_mm; + + /* + * __mmdrop() is a heavy operation and we don't need RCU + * protection here. Release RCU lock during these operations. + * We reinstate the RCU read lock as the caller expects it to + * be held when this function returns even on error. + */ + rcu_read_unlock(); + mmgrab(other_mm); + vma_refcount_put(vma); + mmdrop(other_mm); + rcu_read_lock(); + return NULL; + } + /* * Overflow of vm_lock_seq/mm_lock_seq might produce false locked result. * False unlocked result is impossible because we modify and check --- a/mm/mmap_lock.c~mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped +++ a/mm/mmap_lock.c @@ -164,8 +164,7 @@ retry: */ /* Check if the vma we locked is the right one. */ - if (unlikely(vma->vm_mm != mm || - address < vma->vm_start || address >= vma->vm_end)) + if (unlikely(address < vma->vm_start || address >= vma->vm_end)) goto inval_end_read; rcu_read_unlock(); @@ -236,11 +235,8 @@ retry: goto fallback; } - /* - * Verify the vma we locked belongs to the same address space and it's - * not behind of the last search position. - */ - if (unlikely(vma->vm_mm != mm || from_addr >= vma->vm_end)) + /* Verify the vma is not behind the last search position. */ + if (unlikely(from_addr >= vma->vm_end)) goto fallback_unlock; /* _ Patches currently in -mm which might be from surenb(a)google.com are

1 month

1
0
0 0

[merged mm-stable] mm-shmem-swap-improve-cached-mthp-handling-and-fix-potential-hang.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/shmem, swap: improve cached mTHP handling and fix potential hang has been removed from the -mm tree. Its filename was mm-shmem-swap-improve-cached-mthp-handling-and-fix-potential-hang.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Kairui Song <kasong(a)tencent.com> Subject: mm/shmem, swap: improve cached mTHP handling and fix potential hang Date: Mon, 28 Jul 2025 15:52:59 +0800 The current swap-in code assumes that, when a swap entry in shmem mapping is order 0, its cached folios (if present) must be order 0 too, which turns out not always correct. The problem is shmem_split_large_entry is called before verifying the folio will eventually be swapped in, one possible race is: CPU1 CPU2 shmem_swapin_folio /* swap in of order > 0 swap entry S1 */ folio = swap_cache_get_folio /* folio = NULL */ order = xa_get_order /* order > 0 */ folio = shmem_swap_alloc_folio /* mTHP alloc failure, folio = NULL */ <... Interrupted ...> shmem_swapin_folio /* S1 is swapped in */ shmem_writeout /* S1 is swapped out, folio cached */ shmem_split_large_entry(..., S1) /* S1 is split, but the folio covering it has order > 0 now */ Now any following swapin of S1 will hang: `xa_get_order` returns 0, and folio lookup will return a folio with order > 0. The `xa_get_order(&mapping->i_pages, index) != folio_order(folio)` will always return false causing swap-in to return -EEXIST. And this looks fragile. So fix this up by allowing seeing a larger folio in swap cache, and check the whole shmem mapping range covered by the swapin have the right swap value upon inserting the folio. And drop the redundant tree walks before the insertion. This will actually improve performance, as it avoids two redundant Xarray tree walks in the hot path, and the only side effect is that in the failure path, shmem may redundantly reallocate a few folios causing temporary slight memory pressure. And worth noting, it may seems the order and value check before inserting might help reducing the lock contention, which is not true. The swap cache layer ensures raced swapin will either see a swap cache folio or failed to do a swapin (we have SWAP_HAS_CACHE bit even if swap cache is bypassed), so holding the folio lock and checking the folio flag is already good enough for avoiding the lock contention. The chance that a folio passes the swap entry value check but the shmem mapping slot has changed should be very low. Link: https://lkml.kernel.org/r/20250728075306.12704-1-ryncsn@gmail.com Link: https://lkml.kernel.org/r/20250728075306.12704-2-ryncsn@gmail.com Fixes: 809bc86517cc ("mm: shmem: support large folio swap out") Signed-off-by: Kairui Song <kasong(a)tencent.com> Reviewed-by: Kemeng Shi <shikemeng(a)huaweicloud.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Tested-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Chris Li <chrisl(a)kernel.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Dev Jain <dev.jain(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 39 ++++++++++++++++++++++++++++++--------- 1 file changed, 30 insertions(+), 9 deletions(-) --- a/mm/shmem.c~mm-shmem-swap-improve-cached-mthp-handling-and-fix-potential-hang +++ a/mm/shmem.c @@ -891,7 +891,9 @@ static int shmem_add_to_page_cache(struc pgoff_t index, void *expected, gfp_t gfp) { XA_STATE_ORDER(xas, &mapping->i_pages, index, folio_order(folio)); - long nr = folio_nr_pages(folio); + unsigned long nr = folio_nr_pages(folio); + swp_entry_t iter, swap; + void *entry; VM_BUG_ON_FOLIO(index != round_down(index, nr), folio); VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); @@ -903,14 +905,25 @@ static int shmem_add_to_page_cache(struc gfp &= GFP_RECLAIM_MASK; folio_throttle_swaprate(folio, gfp); + swap = radix_to_swp_entry(expected); do { + iter = swap; xas_lock_irq(&xas); - if (expected != xas_find_conflict(&xas)) { - xas_set_err(&xas, -EEXIST); - goto unlock; + xas_for_each_conflict(&xas, entry) { + /* + * The range must either be empty, or filled with + * expected swap entries. Shmem swap entries are never + * partially freed without split of both entry and + * folio, so there shouldn't be any holes. + */ + if (!expected || entry != swp_to_radix_entry(iter)) { + xas_set_err(&xas, -EEXIST); + goto unlock; + } + iter.val += 1 << xas_get_order(&xas); } - if (expected && xas_find_conflict(&xas)) { + if (expected && iter.val - nr != swap.val) { xas_set_err(&xas, -EEXIST); goto unlock; } @@ -2359,7 +2372,7 @@ static int shmem_swapin_folio(struct ino error = -ENOMEM; goto failed; } - } else if (order != folio_order(folio)) { + } else if (order > folio_order(folio)) { /* * Swap readahead may swap in order 0 folios into swapcache * asynchronously, while the shmem mapping can still stores @@ -2384,15 +2397,23 @@ static int shmem_swapin_folio(struct ino swap = swp_entry(swp_type(swap), swp_offset(swap) + offset); } + } else if (order < folio_order(folio)) { + swap.val = round_down(swap.val, 1 << folio_order(folio)); + index = round_down(index, 1 << folio_order(folio)); } alloced: - /* We have to do this with folio locked to prevent races */ + /* + * We have to do this with the folio locked to prevent races. + * The shmem_confirm_swap below only checks if the first swap + * entry matches the folio, that's enough to ensure the folio + * is not used outside of shmem, as shmem swap entries + * and swap cache folios are never partially freed. + */ folio_lock(folio); if ((!skip_swapcache && !folio_test_swapcache(folio)) || - folio->swap.val != swap.val || !shmem_confirm_swap(mapping, index, swap) || - xa_get_order(&mapping->i_pages, index) != folio_order(folio)) { + folio->swap.val != swap.val) { error = -EEXIST; goto unlock; } _ Patches currently in -mm which might be from kasong(a)tencent.com are

1 month

1
0
0 0

[folded-merged] mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped-v3.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped-v3 has been removed from the -mm tree. Its filename was mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped-v3.patch This patch was dropped because it was folded into mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped.patch ------------------------------------------------------ From: Suren Baghdasaryan <surenb(a)google.com> Subject: mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped-v3 Date: Tue, 29 Jul 2025 07:57:09 -0700 - Addressed Lorenzo's nits, per Lorenzo Stoakes - Added a warning comment for vma_start_read() - Added Reviewed-by and Acked-by, per Vlastimil Babka and Lorenzo Stoakes Link: https://lkml.kernel.org/r/20250729145709.2731370-1-surenb@google.com Fixes: 3104138517fc ("mm: make vma cache SLAB_TYPESAFE_BY_RCU") Reported-by: Jann Horn <jannh(a)google.com> Closes: https://lore.kernel.org/all/CAG48ez0-deFbVH=E3jbkWx=X3uVbd8nWeo6kbJPQ0KoUD+… Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Acked-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mmap_lock.h | 7 +++++++ mm/mmap_lock.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) --- a/include/linux/mmap_lock.h~mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped-v3 +++ a/include/linux/mmap_lock.h @@ -155,6 +155,10 @@ static inline void vma_refcount_put(stru * reused and attached to a different mm before we lock it. * Returns the vma on success, NULL on failure to lock and EAGAIN if vma got * detached. + * + * WARNING! The vma passed to this function cannot be used if the function + * fails to lock it because in certain cases RCU lock is dropped and then + * reacquired. Once RCU lock is dropped the vma can be concurently freed. */ static inline struct vm_area_struct *vma_start_read(struct mm_struct *mm, struct vm_area_struct *vma) @@ -194,9 +198,12 @@ static inline struct vm_area_struct *vma if (unlikely(vma->vm_mm != mm)) { /* Use a copy of vm_mm in case vma is freed after we drop vm_refcnt */ struct mm_struct *other_mm = vma->vm_mm; + /* * __mmdrop() is a heavy operation and we don't need RCU * protection here. Release RCU lock during these operations. + * We reinstate the RCU read lock as the caller expects it to + * be held when this function returns even on error. */ rcu_read_unlock(); mmgrab(other_mm); --- a/mm/mmap_lock.c~mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped-v3 +++ a/mm/mmap_lock.c @@ -235,7 +235,7 @@ retry: goto fallback; } - /* Verify the vma is not behind of the last search position. */ + /* Verify the vma is not behind the last search position. */ if (unlikely(from_addr >= vma->vm_end)) goto fallback_unlock; _ Patches currently in -mm which might be from surenb(a)google.com are mm-fix-a-uaf-when-vma-mm-is-freed-after-vma-vm_refcnt-got-dropped.patch

1 month

1
0
0 0

[PATCH 0/5] drm/i915: fixes for i915 Hot Plug Detection and build/runtime issues

by Nicusor Huhulea

Hello maintainers, This series addresses a defect observed on certain hardware platforms using Linux kernel 6.1.147 with the i915 driver. The issue concerns hot plug detection (HPD) logic, leading to unreliable or missed detection events on affected hardware. This is happening on some specific devices. ### Background Issue: On Simatic IPC227E, we observed unreliable or missing hot plug detection events, while on Simatic IPC227G (otherwise similar platform), expected hot plug behavior was maintained. Affected kernel: This patch series is intended for the Linux 6.1.y stable tree only (tested on 6.1.147) Most of the tests were conducted on 6.1.147 (manual/standalone kernel build, CIP/Isar context). Root cause analysis: I do not have access to hardware signal traces or scope data to conclusively prove the root cause at electrical level. My understanding is based on observed driver behavior and logs. Therefore my assumption as to the real cause is that on IPC227G, HPD IRQ storms are apparently not occurring, so the standard HPD IRQ-based detection works as expected. On IPC227E, frequent HPD interrupts trigger the i915 driver’s storm detection logic, causing it to switch to polling mode. Therefore polling does not resume correctly, leading to the hotplug issue this series addresses. Device IPC227E's behavior triggers this kernel edge case, likely due to slight variations in signal integrity, electrical margins, or internal component timing. Device IPC227G, functions as expected, possibly due to cleaner electrical signaling or more optimal timing characteristics, thus avoiding the triggering condition. Conclusion: This points to a hardware-software interaction where kernel code assumes nicer signaling or margins than IPC227E is able to provide, exposing logic gaps not visible on more robust hardware. ### Patches Patches 1-4: - Partial backports of upstream commits; only the relevant logic or fixes are applied, with other code omitted due to downstream divergence. - Applied minimal merging without exhaustive backport of all intermediate upstream changes. Patch 5: - Contains cherry-picked logic plus context/compatibility amendments as needed. Ensures that the driver builds. - Together these fixes greatly improve reliability of hotplug detection on both devices, with no regression detected in our setups. Thank you for your review, Nicusor Huhulea This patch series contains the following changes: Dmitry Baryshkov (2): drm/probe_helper: extract two helper functions drm/probe-helper: enable and disable HPD on connectors Imre Deak (2): drm/i915: Fix HPD polling, reenabling the output poll work as needed drm: Add an HPD poll helper to reschedule the poll work Nicusor Huhulea (1): drm/i915: fixes for i915 Hot Plug Detection and build/runtime issues drivers/gpu/drm/drm_probe_helper.c | 127 ++++++++++++++----- drivers/gpu/drm/i915/display/intel_hotplug.c | 4 +- include/drm/drm_modeset_helper_vtables.h | 22 ++++ include/drm/drm_probe_helper.h | 1 + 4 files changed, 122 insertions(+), 32 deletions(-) -- 2.39.2

1 month

4
10
0 0

+ mm-fix-possible-deadlock-in-console_trylock_spinning.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix possible deadlock in console_trylock_spinning has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-possible-deadlock-in-console_trylock_spinning.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Gu Bowen <gubowen5(a)huawei.com> Subject: mm: fix possible deadlock in console_trylock_spinning Date: Wed, 30 Jul 2025 17:49:14 +0800 kmemleak_scan_thread() invokes scan_block() which may invoke a nomal printk() to print warning message. This can cause a deadlock in the scenario reported below: CPU0 CPU1 ---- ---- lock(kmemleak_lock); lock(&port->lock); lock(kmemleak_lock); lock(console_owner); To solve this problem, switch to printk_safe mode before printing warning message, this will redirect all printk()-s to a special per-CPU buffer, which will be flushed later from a safe context (irq work), and this deadlock problem can be avoided. Our syztester report the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.10.0-22221-gca646a51dd00 #16 Not tainted ------------------------------------------------------ kmemleak/182 is trying to acquire lock: ffffffffaf9e9020 (console_owner){-...}-{0:0}, at: console_trylock_spinning+0xda/0x1d0 kernel/printk/printk.c:1900 but task is already holding lock: ffffffffb007cf58 (kmemleak_lock){-.-.}-{2:2}, at: scan_block+0x3d/0x220 mm/kmemleak.c:1310 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kmemleak_lock){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 create_object.isra.0+0x36/0x80 mm/kmemleak.c:691 kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] slab_post_alloc_hook mm/slab.h:518 [inline] slab_alloc_node mm/slub.c:2987 [inline] slab_alloc mm/slub.c:2995 [inline] __kmalloc+0x637/0xb60 mm/slub.c:4100 kmalloc include/linux/slab.h:620 [inline] tty_buffer_alloc+0x127/0x140 drivers/tty/tty_buffer.c:176 __tty_buffer_request_room+0x9b/0x110 drivers/tty/tty_buffer.c:276 tty_insert_flip_string_fixed_flag+0x60/0x130 drivers/tty/tty_buffer.c:321 tty_insert_flip_string include/linux/tty_flip.h:36 [inline] tty_insert_flip_string_and_push_buffer+0x3a/0xb0 drivers/tty/tty_buffer.c:578 process_output_block+0xc2/0x2e0 drivers/tty/n_tty.c:592 n_tty_write+0x298/0x540 drivers/tty/n_tty.c:2433 do_tty_write drivers/tty/tty_io.c:1041 [inline] file_tty_write.constprop.0+0x29b/0x4b0 drivers/tty/tty_io.c:1147 redirected_tty_write+0x51/0x90 drivers/tty/tty_io.c:1176 call_write_iter include/linux/fs.h:2117 [inline] do_iter_readv_writev+0x274/0x350 fs/read_write.c:741 do_iter_write+0xbb/0x1f0 fs/read_write.c:867 vfs_writev+0xfa/0x380 fs/read_write.c:940 do_writev+0xd6/0x1d0 fs/read_write.c:983 do_syscall_64+0x2b/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x6c/0xd6 -> #2 (&port->lock){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 tty_port_tty_get+0x1f/0xa0 drivers/tty/tty_port.c:289 tty_port_default_wakeup+0xb/0x30 drivers/tty/tty_port.c:48 serial8250_tx_chars+0x259/0x430 drivers/tty/serial/8250/8250_port.c:1906 __start_tx drivers/tty/serial/8250/8250_port.c:1598 [inline] serial8250_start_tx+0x304/0x320 drivers/tty/serial/8250/8250_port.c:1720 uart_write+0x1a1/0x2e0 drivers/tty/serial/serial_core.c:635 do_output_char+0x2c0/0x370 drivers/tty/n_tty.c:444 process_output drivers/tty/n_tty.c:511 [inline] n_tty_write+0x269/0x540 drivers/tty/n_tty.c:2445 do_tty_write drivers/tty/tty_io.c:1041 [inline] file_tty_write.constprop.0+0x29b/0x4b0 drivers/tty/tty_io.c:1147 call_write_iter include/linux/fs.h:2117 [inline] do_iter_readv_writev+0x274/0x350 fs/read_write.c:741 do_iter_write+0xbb/0x1f0 fs/read_write.c:867 vfs_writev+0xfa/0x380 fs/read_write.c:940 do_writev+0xd6/0x1d0 fs/read_write.c:983 do_syscall_64+0x2b/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x6c/0xd6 -> #1 (&port_lock_key){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 serial8250_console_write+0x292/0x320 drivers/tty/serial/8250/8250_port.c:3458 call_console_drivers.constprop.0+0x185/0x240 kernel/printk/printk.c:1988 console_unlock+0x2b4/0x640 kernel/printk/printk.c:2648 register_console.part.0+0x2a1/0x390 kernel/printk/printk.c:3024 univ8250_console_init+0x24/0x2b drivers/tty/serial/8250/8250_core.c:724 console_init+0x188/0x24b kernel/printk/printk.c:3134 start_kernel+0x2b0/0x41e init/main.c:1072 secondary_startup_64_no_verify+0xc3/0xcb -> #0 (console_owner){-...}-{0:0}: check_prev_add+0xfa/0x1380 kernel/locking/lockdep.c:2988 check_prevs_add+0x1d8/0x3c0 kernel/locking/lockdep.c:3113 validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 console_trylock_spinning+0x10d/0x1d0 kernel/printk/printk.c:1921 vprintk_emit+0x1a5/0x270 kernel/printk/printk.c:2134 printk+0xb2/0xe7 kernel/printk/printk.c:2183 lookup_object.cold+0xf/0x24 mm/kmemleak.c:405 scan_block+0x1fa/0x220 mm/kmemleak.c:1357 scan_object+0xdd/0x140 mm/kmemleak.c:1415 scan_gray_list+0x8f/0x1c0 mm/kmemleak.c:1453 kmemleak_scan+0x649/0xf30 mm/kmemleak.c:1608 kmemleak_scan_thread+0x94/0xb6 mm/kmemleak.c:1721 kthread+0x1c4/0x210 kernel/kthread.c:328 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:299 other info that might help us debug this: Chain exists of: console_owner --> &port->lock --> kmemleak_lock Link: https://lkml.kernel.org/r/20250730094914.566582-1-gubowen5@huawei.com Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Lu Jialin <lujialin4(a)huawei.com> Cc: Waiman Long <longman(a)redhat.com> Cc: Breno Leitao <leitao(a)debian.org> Cc: <stable(a)vger.kernel.org> [5.10+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kmemleak.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/kmemleak.c~mm-fix-possible-deadlock-in-console_trylock_spinning +++ a/mm/kmemleak.c @@ -437,9 +437,11 @@ static struct kmemleak_object *__lookup_ else if (untagged_objp == untagged_ptr || alias) return object; else { + __printk_safe_enter(); kmemleak_warn("Found object by alias at 0x%08lx\n", ptr); dump_object_info(object); + __printk_safe_exit(); break; } } _ Patches currently in -mm which might be from gubowen5(a)huawei.com are mm-fix-possible-deadlock-in-console_trylock_spinning.patch

1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025