May 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] comedi: jr3_pci: Fix synchronous deletion of timer" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 44d9b3f584c59a606b521e7274e658d5b866c699 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042808-vastly-armrest-7811@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 44d9b3f584c59a606b521e7274e658d5b866c699 Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Tue, 15 Apr 2025 13:39:01 +0100 Subject: [PATCH] comedi: jr3_pci: Fix synchronous deletion of timer When `jr3_pci_detach()` is called during device removal, it calls `timer_delete_sync()` to stop the timer, but the timer expiry function always reschedules the timer, so the synchronization is ineffective. Call `timer_shutdown_sync()` instead. It does not matter that the timer expiry function pointer is cleared, because the device is being removed. Fixes: 07b509e6584a5 ("Staging: comedi: add jr3_pci driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Link: https://lore.kernel.org/r/20250415123901.13483-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/comedi/drivers/jr3_pci.c b/drivers/comedi/drivers/jr3_pci.c index cdc842b32bab..75dce1ff2419 100644 --- a/drivers/comedi/drivers/jr3_pci.c +++ b/drivers/comedi/drivers/jr3_pci.c @@ -758,7 +758,7 @@ static void jr3_pci_detach(struct comedi_device *dev) struct jr3_pci_dev_private *devpriv = dev->private; if (devpriv) - timer_delete_sync(&devpriv->timer); + timer_shutdown_sync(&devpriv->timer); comedi_pci_detach(dev); }

6 days, 17 hours

3
2
0 0

FAILED: patch "[PATCH] binder: fix offset calculation in debug log" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 170d1a3738908eef6a0dbf378ea77fb4ae8e294d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042803-deflected-overdue-01a5@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 170d1a3738908eef6a0dbf378ea77fb4ae8e294d Mon Sep 17 00:00:00 2001 From: Carlos Llamas <cmllamas(a)google.com> Date: Tue, 25 Mar 2025 18:49:00 +0000 Subject: [PATCH] binder: fix offset calculation in debug log The vma start address should be substracted from the buffer's user data address and not the other way around. Cc: Tiffany Y. Yang <ynaffit(a)google.com> Cc: stable <stable(a)kernel.org> Fixes: 162c79731448 ("binder: avoid user addresses in debug logs") Signed-off-by: Carlos Llamas <cmllamas(a)google.com> Reviewed-by: Tiffany Y. Yang <ynaffit(a)google.com> Link: https://lore.kernel.org/r/20250325184902.587138-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/android/binder.c b/drivers/android/binder.c index 76052006bd87..5fc2c8ee61b1 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -6373,7 +6373,7 @@ static void print_binder_transaction_ilocked(struct seq_file *m, seq_printf(m, " node %d", buffer->target_node->debug_id); seq_printf(m, " size %zd:%zd offset %lx\n", buffer->data_size, buffer->offsets_size, - proc->alloc.vm_start - buffer->user_data); + buffer->user_data - proc->alloc.vm_start); } static void print_binder_work_ilocked(struct seq_file *m,

6 days, 17 hours

3
2
0 0

[PATCH stable v6.6] riscv: kprobes: Fix wrong lengths passed to patch_text_nosync()

by Nam Cao

Unlike patch_text(), patch_text_nosync() takes the length in bytes, not number of instructions. It is therefore wrong for arch_prepare_ss_slot() to pass length=1 while patching one instruction. This bug was introduced by commit b1756750a397 ("riscv: kprobes: Use patch_text_nosync() for insn slots"). It has been fixed upstream by commit 51781ce8f448 ("riscv: Pass patch_text() the length in bytes"). However, beside fixing this bug, this commit does many other things, making it unsuitable for backporting. Fix it by properly passing the lengths in bytes. Fixes: b1756750a397 ("riscv: kprobes: Use patch_text_nosync() for insn slots") Signed-off-by: Nam Cao <namcao(a)linutronix.de> --- arch/riscv/kernel/probes/kprobes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/probes/kprobes.c b/arch/riscv/kernel/probes/kprobes.c index 4fbc70e823f0..dc431b965bc3 100644 --- a/arch/riscv/kernel/probes/kprobes.c +++ b/arch/riscv/kernel/probes/kprobes.c @@ -28,8 +28,8 @@ static void __kprobes arch_prepare_ss_slot(struct kprobe *p) p->ainsn.api.restore = (unsigned long)p->addr + offset; - patch_text_nosync(p->ainsn.api.insn, &p->opcode, 1); - patch_text_nosync((void *)p->ainsn.api.insn + offset, &insn, 1); + patch_text_nosync(p->ainsn.api.insn, &p->opcode, offset); + patch_text_nosync((void *)p->ainsn.api.insn + offset, &insn, sizeof(insn)); } static void __kprobes arch_prepare_simulate(struct kprobe *p) -- 2.39.5

6 days, 17 hours

3
4
0 0

FAILED: patch "[PATCH] comedi: jr3_pci: Fix synchronous deletion of timer" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 44d9b3f584c59a606b521e7274e658d5b866c699 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042807-vanquish-unbeaten-57ab@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 44d9b3f584c59a606b521e7274e658d5b866c699 Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Tue, 15 Apr 2025 13:39:01 +0100 Subject: [PATCH] comedi: jr3_pci: Fix synchronous deletion of timer When `jr3_pci_detach()` is called during device removal, it calls `timer_delete_sync()` to stop the timer, but the timer expiry function always reschedules the timer, so the synchronization is ineffective. Call `timer_shutdown_sync()` instead. It does not matter that the timer expiry function pointer is cleared, because the device is being removed. Fixes: 07b509e6584a5 ("Staging: comedi: add jr3_pci driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Link: https://lore.kernel.org/r/20250415123901.13483-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/comedi/drivers/jr3_pci.c b/drivers/comedi/drivers/jr3_pci.c index cdc842b32bab..75dce1ff2419 100644 --- a/drivers/comedi/drivers/jr3_pci.c +++ b/drivers/comedi/drivers/jr3_pci.c @@ -758,7 +758,7 @@ static void jr3_pci_detach(struct comedi_device *dev) struct jr3_pci_dev_private *devpriv = dev->private; if (devpriv) - timer_delete_sync(&devpriv->timer); + timer_shutdown_sync(&devpriv->timer); comedi_pci_detach(dev); }

6 days, 17 hours

3
2
0 0

FAILED: patch "[PATCH] comedi: jr3_pci: Fix synchronous deletion of timer" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 44d9b3f584c59a606b521e7274e658d5b866c699 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042808-difficult-germicide-075a@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 44d9b3f584c59a606b521e7274e658d5b866c699 Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Tue, 15 Apr 2025 13:39:01 +0100 Subject: [PATCH] comedi: jr3_pci: Fix synchronous deletion of timer When `jr3_pci_detach()` is called during device removal, it calls `timer_delete_sync()` to stop the timer, but the timer expiry function always reschedules the timer, so the synchronization is ineffective. Call `timer_shutdown_sync()` instead. It does not matter that the timer expiry function pointer is cleared, because the device is being removed. Fixes: 07b509e6584a5 ("Staging: comedi: add jr3_pci driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Link: https://lore.kernel.org/r/20250415123901.13483-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/comedi/drivers/jr3_pci.c b/drivers/comedi/drivers/jr3_pci.c index cdc842b32bab..75dce1ff2419 100644 --- a/drivers/comedi/drivers/jr3_pci.c +++ b/drivers/comedi/drivers/jr3_pci.c @@ -758,7 +758,7 @@ static void jr3_pci_detach(struct comedi_device *dev) struct jr3_pci_dev_private *devpriv = dev->private; if (devpriv) - timer_delete_sync(&devpriv->timer); + timer_shutdown_sync(&devpriv->timer); comedi_pci_detach(dev); }

6 days, 17 hours

3
2
0 0

[to-be-updated] mm-userfaultfd-prevent-busy-looping-for-tasks-with-signals-pending.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/userfaultfd: prevent busy looping for tasks with signals pending has been removed from the -mm tree. Its filename was mm-userfaultfd-prevent-busy-looping-for-tasks-with-signals-pending.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Jens Axboe <axboe(a)kernel.dk> Subject: mm/userfaultfd: prevent busy looping for tasks with signals pending Date: Wed, 23 Apr 2025 17:37:06 -0600 userfaultfd may use interruptible sleeps to wait on userspace filling a page fault, which works fine if the task can be reliably put to sleeping waiting for that. However, if the task has a normal (ie non-fatal) signal pending, then TASK_INTERRUPTIBLE sleep will simply cause schedule() to be a no-op. For a task that registers a page with userfaultfd and then proceeds to do a write from it, if that task also has a signal pending then it'll essentially busy loop from do_page_fault() -> handle_userfault() until that fault has been filled. Normally it'd be expected that the task would sleep until that happens. Here's a trace from an application doing just that: handle_userfault+0x4b8/0xa00 (P) hugetlb_fault+0xe24/0x1060 handle_mm_fault+0x2bc/0x318 do_page_fault+0x1e8/0x6f0 do_translation_fault+0x9c/0xd0 do_mem_abort+0x44/0xa0 el1_abort+0x3c/0x68 el1h_64_sync_handler+0xd4/0x100 el1h_64_sync+0x6c/0x70 fault_in_readable+0x74/0x108 (P) iomap_file_buffered_write+0x14c/0x438 blkdev_write_iter+0x1a8/0x340 vfs_write+0x20c/0x348 ksys_write+0x64/0x108 __arm64_sys_write+0x1c/0x38 where the task is looping with 100% CPU time in the above mentioned fault path. Since it's impossible to handle signals, or other conditions like TIF_NOTIFY_SIGNAL that also prevents interruptible sleeping, from the fault path, use TASK_UNINTERRUPTIBLE with a short timeout even for vmf modes that would normally ask for INTERRUPTIBLE or KILLABLE sleep. Fatal signals will still be handled by the caller, and the timeout is short enough to hopefully not cause any issues. If this is the first invocation of this fault, eg FAULT_FLAG_TRIED isn't set, then the normal sleep mode is used. Link: https://lkml.kernel.org/r/27c3a7f5-aad8-4f2a-a66e-ff5ae98f31eb@kernel.dk Fixes: 4064b9827063 ("mm: allow VM_FAULT_RETRY for multiple times") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Reported-by: Zhiwei Jiang <qq282012236(a)gmail.com> Closes: https://lore.kernel.org/io-uring/20250422162913.1242057-1-qq282012236@gmail… Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) --- a/fs/userfaultfd.c~mm-userfaultfd-prevent-busy-looping-for-tasks-with-signals-pending +++ a/fs/userfaultfd.c @@ -334,15 +334,29 @@ out: return ret; } -static inline unsigned int userfaultfd_get_blocking_state(unsigned int flags) +struct userfault_wait { + unsigned int task_state; + bool timeout; +}; + +static struct userfault_wait userfaultfd_get_blocking_state(unsigned int flags) { + /* + * If the fault has already been tried AND there's a signal pending + * for this task, use TASK_UNINTERRUPTIBLE with a small timeout. + * This prevents busy looping where schedule() otherwise does nothing + * for TASK_INTERRUPTIBLE when the task has a signal pending. + */ + if ((flags & FAULT_FLAG_TRIED) && signal_pending(current)) + return (struct userfault_wait) { TASK_UNINTERRUPTIBLE, true }; + if (flags & FAULT_FLAG_INTERRUPTIBLE) - return TASK_INTERRUPTIBLE; + return (struct userfault_wait) { TASK_INTERRUPTIBLE, false }; if (flags & FAULT_FLAG_KILLABLE) - return TASK_KILLABLE; + return (struct userfault_wait) { TASK_KILLABLE, false }; - return TASK_UNINTERRUPTIBLE; + return (struct userfault_wait) { TASK_UNINTERRUPTIBLE, false }; } /* @@ -368,7 +382,7 @@ vm_fault_t handle_userfault(struct vm_fa struct userfaultfd_wait_queue uwq; vm_fault_t ret = VM_FAULT_SIGBUS; bool must_wait; - unsigned int blocking_state; + struct userfault_wait wait_mode; /* * We don't do userfault handling for the final child pid update @@ -466,7 +480,7 @@ vm_fault_t handle_userfault(struct vm_fa uwq.ctx = ctx; uwq.waken = false; - blocking_state = userfaultfd_get_blocking_state(vmf->flags); + wait_mode = userfaultfd_get_blocking_state(vmf->flags); /* * Take the vma lock now, in order to safely call @@ -488,7 +502,7 @@ vm_fault_t handle_userfault(struct vm_fa * following the spin_unlock to happen before the list_add in * __add_wait_queue. */ - set_current_state(blocking_state); + set_current_state(wait_mode.task_state); spin_unlock_irq(&ctx->fault_pending_wqh.lock); if (!is_vm_hugetlb_page(vma)) @@ -501,7 +515,11 @@ vm_fault_t handle_userfault(struct vm_fa if (likely(must_wait && !READ_ONCE(ctx->released))) { wake_up_poll(&ctx->fd_wqh, EPOLLIN); - schedule(); + /* See comment in userfaultfd_get_blocking_state() */ + if (!wait_mode.timeout) + schedule(); + else + schedule_timeout(HZ / 10); } __set_current_state(TASK_RUNNING); _ Patches currently in -mm which might be from axboe(a)kernel.dk are

6 days, 18 hours

1
0
0 0

+ mm-userfaultfd-prevent-busy-looping-for-tasks-with-signals-pending.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/userfaultfd: prevent busy looping for tasks with signals pending has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-userfaultfd-prevent-busy-looping-for-tasks-with-signals-pending.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: Jens Axboe <axboe(a)kernel.dk> Subject: mm/userfaultfd: prevent busy looping for tasks with signals pending Date: Wed, 23 Apr 2025 17:37:06 -0600 userfaultfd may use interruptible sleeps to wait on userspace filling a page fault, which works fine if the task can be reliably put to sleeping waiting for that. However, if the task has a normal (ie non-fatal) signal pending, then TASK_INTERRUPTIBLE sleep will simply cause schedule() to be a no-op. For a task that registers a page with userfaultfd and then proceeds to do a write from it, if that task also has a signal pending then it'll essentially busy loop from do_page_fault() -> handle_userfault() until that fault has been filled. Normally it'd be expected that the task would sleep until that happens. Here's a trace from an application doing just that: handle_userfault+0x4b8/0xa00 (P) hugetlb_fault+0xe24/0x1060 handle_mm_fault+0x2bc/0x318 do_page_fault+0x1e8/0x6f0 do_translation_fault+0x9c/0xd0 do_mem_abort+0x44/0xa0 el1_abort+0x3c/0x68 el1h_64_sync_handler+0xd4/0x100 el1h_64_sync+0x6c/0x70 fault_in_readable+0x74/0x108 (P) iomap_file_buffered_write+0x14c/0x438 blkdev_write_iter+0x1a8/0x340 vfs_write+0x20c/0x348 ksys_write+0x64/0x108 __arm64_sys_write+0x1c/0x38 where the task is looping with 100% CPU time in the above mentioned fault path. Since it's impossible to handle signals, or other conditions like TIF_NOTIFY_SIGNAL that also prevents interruptible sleeping, from the fault path, use TASK_UNINTERRUPTIBLE with a short timeout even for vmf modes that would normally ask for INTERRUPTIBLE or KILLABLE sleep. Fatal signals will still be handled by the caller, and the timeout is short enough to hopefully not cause any issues. If this is the first invocation of this fault, eg FAULT_FLAG_TRIED isn't set, then the normal sleep mode is used. Link: https://lkml.kernel.org/r/27c3a7f5-aad8-4f2a-a66e-ff5ae98f31eb@kernel.dk Fixes: 4064b9827063 ("mm: allow VM_FAULT_RETRY for multiple times") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Reported-by: Zhiwei Jiang <qq282012236(a)gmail.com> Closes: https://lore.kernel.org/io-uring/20250422162913.1242057-1-qq282012236@gmail… Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) --- a/fs/userfaultfd.c~mm-userfaultfd-prevent-busy-looping-for-tasks-with-signals-pending +++ a/fs/userfaultfd.c @@ -334,15 +334,29 @@ out: return ret; } -static inline unsigned int userfaultfd_get_blocking_state(unsigned int flags) +struct userfault_wait { + unsigned int task_state; + bool timeout; +}; + +static struct userfault_wait userfaultfd_get_blocking_state(unsigned int flags) { + /* + * If the fault has already been tried AND there's a signal pending + * for this task, use TASK_UNINTERRUPTIBLE with a small timeout. + * This prevents busy looping where schedule() otherwise does nothing + * for TASK_INTERRUPTIBLE when the task has a signal pending. + */ + if ((flags & FAULT_FLAG_TRIED) && signal_pending(current)) + return (struct userfault_wait) { TASK_UNINTERRUPTIBLE, true }; + if (flags & FAULT_FLAG_INTERRUPTIBLE) - return TASK_INTERRUPTIBLE; + return (struct userfault_wait) { TASK_INTERRUPTIBLE, false }; if (flags & FAULT_FLAG_KILLABLE) - return TASK_KILLABLE; + return (struct userfault_wait) { TASK_KILLABLE, false }; - return TASK_UNINTERRUPTIBLE; + return (struct userfault_wait) { TASK_UNINTERRUPTIBLE, false }; } /* @@ -368,7 +382,7 @@ vm_fault_t handle_userfault(struct vm_fa struct userfaultfd_wait_queue uwq; vm_fault_t ret = VM_FAULT_SIGBUS; bool must_wait; - unsigned int blocking_state; + struct userfault_wait wait_mode; /* * We don't do userfault handling for the final child pid update @@ -466,7 +480,7 @@ vm_fault_t handle_userfault(struct vm_fa uwq.ctx = ctx; uwq.waken = false; - blocking_state = userfaultfd_get_blocking_state(vmf->flags); + wait_mode = userfaultfd_get_blocking_state(vmf->flags); /* * Take the vma lock now, in order to safely call @@ -488,7 +502,7 @@ vm_fault_t handle_userfault(struct vm_fa * following the spin_unlock to happen before the list_add in * __add_wait_queue. */ - set_current_state(blocking_state); + set_current_state(wait_mode.task_state); spin_unlock_irq(&ctx->fault_pending_wqh.lock); if (!is_vm_hugetlb_page(vma)) @@ -501,7 +515,11 @@ vm_fault_t handle_userfault(struct vm_fa if (likely(must_wait && !READ_ONCE(ctx->released))) { wake_up_poll(&ctx->fd_wqh, EPOLLIN); - schedule(); + /* See comment in userfaultfd_get_blocking_state() */ + if (!wait_mode.timeout) + schedule(); + else + schedule_timeout(HZ / 10); } __set_current_state(TASK_RUNNING); _ Patches currently in -mm which might be from axboe(a)kernel.dk are mm-userfaultfd-prevent-busy-looping-for-tasks-with-signals-pending.patch

6 days, 20 hours

2
1
0 0

patch "iio: adc: ad7606: fix serial register access" 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 iio: adc: ad7606: fix serial register access 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 f083f8a21cc785ebe3a33f756a3fa3660611f8db Mon Sep 17 00:00:00 2001 From: Angelo Dureghello <adureghello(a)baylibre.com> Date: Fri, 18 Apr 2025 20:37:53 +0200 Subject: iio: adc: ad7606: fix serial register access Fix register read/write routine as per datasheet. When reading multiple consecutive registers, only the first one is read properly. This is due to missing chip select deassert and assert again between first and second 16bit transfer, as shown in the datasheet AD7606C-16, rev 0, figure 110. Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") Reviewed-by: David Lechner <dlechner(a)baylibre.com> Signed-off-by: Angelo Dureghello <adureghello(a)baylibre.com> Link: https://patch.msgid.link/20250418-wip-bl-ad7606-fix-reg-access-v3-1-d5eeb44… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7606_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7606_spi.c b/drivers/iio/adc/ad7606_spi.c index 885bf0b68e77..179115e90988 100644 --- a/drivers/iio/adc/ad7606_spi.c +++ b/drivers/iio/adc/ad7606_spi.c @@ -131,7 +131,7 @@ static int ad7606_spi_reg_read(struct ad7606_state *st, unsigned int addr) { .tx_buf = &st->d16[0], .len = 2, - .cs_change = 0, + .cs_change = 1, }, { .rx_buf = &st->d16[1], .len = 2, -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: imu: adis16550: align buffers for timestamp" 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 iio: imu: adis16550: align buffers for timestamp 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 e4570f4bb231f01e32d44fd38841665f340d6914 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Fri, 18 Apr 2025 11:17:13 -0500 Subject: iio: imu: adis16550: align buffers for timestamp Align the buffers used with iio_push_to_buffers_with_timestamp() to ensure the s64 timestamp is aligned to 8 bytes. Fixes: bac4368fab62 ("iio: imu: adis16550: add adis16550 support") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250418-iio-more-timestamp-alignment-v2-1-d6a5d2b… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/adis16550.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/imu/adis16550.c b/drivers/iio/imu/adis16550.c index b14ea8937c7f..28f0dbd0226c 100644 --- a/drivers/iio/imu/adis16550.c +++ b/drivers/iio/imu/adis16550.c @@ -836,7 +836,7 @@ static irqreturn_t adis16550_trigger_handler(int irq, void *p) u16 dummy; bool valid; struct iio_poll_func *pf = p; - __be32 data[ADIS16550_MAX_SCAN_DATA]; + __be32 data[ADIS16550_MAX_SCAN_DATA] __aligned(8); struct iio_dev *indio_dev = pf->indio_dev; struct adis16550 *st = iio_priv(indio_dev); struct adis *adis = iio_device_get_drvdata(indio_dev); -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: pressure: mprls0025pa: use aligned_s64 for timestamp" 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 iio: pressure: mprls0025pa: use aligned_s64 for timestamp 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 ffcd19e9f4cca0c8f9e23e88f968711acefbb37b Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Fri, 18 Apr 2025 11:17:14 -0500 Subject: iio: pressure: mprls0025pa: use aligned_s64 for timestamp Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure the struct itself it also 8-byte aligned. While touching this, convert struct mpr_chan to an anonymous struct to consolidate the code a bit to make it easier for future readers. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250418-iio-more-timestamp-alignment-v2-2-d6a5d2b… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/pressure/mprls0025pa.h | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/iio/pressure/mprls0025pa.h b/drivers/iio/pressure/mprls0025pa.h index 9d5c30afa9d6..d62a018eaff3 100644 --- a/drivers/iio/pressure/mprls0025pa.h +++ b/drivers/iio/pressure/mprls0025pa.h @@ -34,16 +34,6 @@ struct iio_dev; struct mpr_data; struct mpr_ops; -/** - * struct mpr_chan - * @pres: pressure value - * @ts: timestamp - */ -struct mpr_chan { - s32 pres; - s64 ts; -}; - enum mpr_func_id { MPR_FUNCTION_A, MPR_FUNCTION_B, @@ -69,6 +59,8 @@ enum mpr_func_id { * reading in a loop until data is ready * @completion: handshake from irq to read * @chan: channel values for buffered mode + * @chan.pres: pressure value + * @chan.ts: timestamp * @buffer: raw conversion data */ struct mpr_data { @@ -87,7 +79,10 @@ struct mpr_data { struct gpio_desc *gpiod_reset; int irq; struct completion completion; - struct mpr_chan chan; + struct { + s32 pres; + aligned_s64 ts; + } chan; u8 buffer[MPR_MEASUREMENT_RD_SIZE] __aligned(IIO_DMA_MINALIGN); }; -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: adc: ad7768-1: Fix insufficient alignment of timestamp." 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 iio: adc: ad7768-1: Fix insufficient alignment of timestamp. 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 ffbc26bc91c1f1eb3dcf5d8776e74cbae21ee13a Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 13 Apr 2025 11:34:25 +0100 Subject: iio: adc: ad7768-1: Fix insufficient alignment of timestamp. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On architectures where an s64 is not 64-bit aligned, this may result insufficient alignment of the timestamp and the structure being too small. Use aligned_s64 to force the alignment. Fixes: a1caeebab07e ("iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp()") # aligned_s64 newer Reported-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Reviewed-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-3-jic23@kernel.org Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7768-1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c index 5a863005aca6..5e0be36af0c5 100644 --- a/drivers/iio/adc/ad7768-1.c +++ b/drivers/iio/adc/ad7768-1.c @@ -168,7 +168,7 @@ struct ad7768_state { union { struct { __be32 chan; - s64 timestamp; + aligned_s64 timestamp; } scan; __be32 d32; u8 d8[2]; -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: adc: ad7266: Fix potential timestamp alignment issue." 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 iio: adc: ad7266: Fix potential timestamp alignment issue. 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 52d349884738c346961e153f195f4c7fe186fcf4 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Sun, 13 Apr 2025 11:34:24 +0100 Subject: iio: adc: ad7266: Fix potential timestamp alignment issue. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On architectures where an s64 is only 32-bit aligned insufficient padding would be left between the earlier elements and the timestamp. Use aligned_s64 to enforce the correct placement and ensure the storage is large enough. Fixes: 54e018da3141 ("iio:ad7266: Mark transfer buffer as __be16") # aligned_s64 is much newer. Reported-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Reviewed-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-2-jic23@kernel.org Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7266.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7266.c b/drivers/iio/adc/ad7266.c index 18559757f908..7fef2727f89e 100644 --- a/drivers/iio/adc/ad7266.c +++ b/drivers/iio/adc/ad7266.c @@ -45,7 +45,7 @@ struct ad7266_state { */ struct { __be16 sample[2]; - s64 timestamp; + aligned_s64 timestamp; } data __aligned(IIO_DMA_MINALIGN); }; -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: chemical: sps30: use aligned_s64 for timestamp" 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 iio: chemical: sps30: use aligned_s64 for timestamp 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 bb49d940344bcb8e2b19e69d7ac86f567887ea9a Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Thu, 17 Apr 2025 11:52:37 -0500 Subject: iio: chemical: sps30: use aligned_s64 for timestamp MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure that the timestamp is correctly aligned on all architectures. Fixes: a5bf6fdd19c3 ("iio:chemical:sps30: Fix timestamp alignment") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-5-eafac1e… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/chemical/sps30.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/chemical/sps30.c b/drivers/iio/chemical/sps30.c index 6f4f2ba2c09d..a7888146188d 100644 --- a/drivers/iio/chemical/sps30.c +++ b/drivers/iio/chemical/sps30.c @@ -108,7 +108,7 @@ static irqreturn_t sps30_trigger_handler(int irq, void *p) int ret; struct { s32 data[4]; /* PM1, PM2P5, PM4, PM10 */ - s64 ts; + aligned_s64 ts; } scan; mutex_lock(&state->lock); -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: chemical: pms7003: use aligned_s64 for timestamp" 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 iio: chemical: pms7003: use aligned_s64 for timestamp 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 6ffa698674053e82e811520642db2650d00d2c01 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Thu, 17 Apr 2025 11:52:36 -0500 Subject: iio: chemical: pms7003: use aligned_s64 for timestamp MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure that the timestamp is correctly aligned on all architectures. Also move the unaligned.h header while touching this since it was the only one not in alphabetical order. Fixes: 13e945631c2f ("iio:chemical:pms7003: Fix timestamp alignment and prevent data leak.") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-4-eafac1e… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/chemical/pms7003.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/iio/chemical/pms7003.c b/drivers/iio/chemical/pms7003.c index d0bd94912e0a..e05ce1f12065 100644 --- a/drivers/iio/chemical/pms7003.c +++ b/drivers/iio/chemical/pms7003.c @@ -5,7 +5,6 @@ * Copyright (c) Tomasz Duszynski <tduszyns(a)gmail.com> */ -#include <linux/unaligned.h> #include <linux/completion.h> #include <linux/device.h> #include <linux/errno.h> @@ -19,6 +18,8 @@ #include <linux/module.h> #include <linux/mutex.h> #include <linux/serdev.h> +#include <linux/types.h> +#include <linux/unaligned.h> #define PMS7003_DRIVER_NAME "pms7003" @@ -76,7 +77,7 @@ struct pms7003_state { /* Used to construct scan to push to the IIO buffer */ struct { u16 data[3]; /* PM1, PM2P5, PM10 */ - s64 ts; + aligned_s64 ts; } scan; }; -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: imu: inv_mpu6050: align buffer for timestamp" 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 iio: imu: inv_mpu6050: align buffer for timestamp 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 1d2d8524eaffc4d9a116213520d2c650e07c9cc6 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Thu, 17 Apr 2025 11:52:39 -0500 Subject: iio: imu: inv_mpu6050: align buffer for timestamp Align the buffer used with iio_push_to_buffers_with_timestamp() to ensure the s64 timestamp is aligned to 8 bytes. Fixes: 0829edc43e0a ("iio: imu: inv_mpu6050: read the full fifo when processing data") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-7-eafac1e… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c index 3d3b27f28c9d..273196e647a2 100644 --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c @@ -50,7 +50,7 @@ irqreturn_t inv_mpu6050_read_fifo(int irq, void *p) u16 fifo_count; u32 fifo_period; s64 timestamp; - u8 data[INV_MPU6050_OUTPUT_DATA_SIZE]; + u8 data[INV_MPU6050_OUTPUT_DATA_SIZE] __aligned(8); size_t i, nb; mutex_lock(&st->lock); -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: adc: ad7606: check for NULL before calling sw_mode_config()" 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 iio: adc: ad7606: check for NULL before calling sw_mode_config() 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 5257d80e22bf27009d6742e4c174f42cfe54e425 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Tue, 18 Mar 2025 17:52:09 -0500 Subject: iio: adc: ad7606: check for NULL before calling sw_mode_config() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Check that the sw_mode_config function pointer is not NULL before calling it. Not all buses define this callback, which resulted in a NULL pointer dereference. Fixes: e571c1902116 ("iio: adc: ad7606: move scale_setup as function pointer on chip-info") Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250318-iio-adc-ad7606-improvements-v2-1-4b605427… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7606.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c index 1a314fddd7eb..703556eb7257 100644 --- a/drivers/iio/adc/ad7606.c +++ b/drivers/iio/adc/ad7606.c @@ -1236,9 +1236,11 @@ static int ad7616_sw_mode_setup(struct iio_dev *indio_dev) st->write_scale = ad7616_write_scale_sw; st->write_os = &ad7616_write_os_sw; - ret = st->bops->sw_mode_config(indio_dev); - if (ret) - return ret; + if (st->bops->sw_mode_config) { + ret = st->bops->sw_mode_config(indio_dev); + if (ret) + return ret; + } /* Activate Burst mode and SEQEN MODE */ return ad7606_write_mask(st, AD7616_CONFIGURATION_REGISTER, @@ -1268,6 +1270,9 @@ static int ad7606b_sw_mode_setup(struct iio_dev *indio_dev) st->write_scale = ad7606_write_scale_sw; st->write_os = &ad7606_write_os_sw; + if (!st->bops->sw_mode_config) + return 0; + return st->bops->sw_mode_config(indio_dev); } -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: adc: rockchip: Fix clock initialization sequence" 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 iio: adc: rockchip: Fix clock initialization sequence 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 839f81de397019f55161c5982d670ac19d836173 Mon Sep 17 00:00:00 2001 From: Simon Xue <xxm(a)rock-chips.com> Date: Wed, 12 Mar 2025 14:20:16 +0800 Subject: iio: adc: rockchip: Fix clock initialization sequence clock_set_rate should be executed after devm_clk_get_enabled. Fixes: 97ad10bb2901 ("iio: adc: rockchip_saradc: Make use of devm_clk_get_enabled") Signed-off-by: Simon Xue <xxm(a)rock-chips.com> Reviewed-by: Heiko Stuebner <heiko(a)sntech.de> Link: https://patch.msgid.link/20250312062016.137821-1-xxm@rock-chips.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/rockchip_saradc.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c index 9a099df79518..5e28bd28b81a 100644 --- a/drivers/iio/adc/rockchip_saradc.c +++ b/drivers/iio/adc/rockchip_saradc.c @@ -520,15 +520,6 @@ static int rockchip_saradc_probe(struct platform_device *pdev) if (info->reset) rockchip_saradc_reset_controller(info->reset); - /* - * Use a default value for the converter clock. - * This may become user-configurable in the future. - */ - ret = clk_set_rate(info->clk, info->data->clk_rate); - if (ret < 0) - return dev_err_probe(&pdev->dev, ret, - "failed to set adc clk rate\n"); - ret = regulator_enable(info->vref); if (ret < 0) return dev_err_probe(&pdev->dev, ret, @@ -555,6 +546,14 @@ static int rockchip_saradc_probe(struct platform_device *pdev) if (IS_ERR(info->clk)) return dev_err_probe(&pdev->dev, PTR_ERR(info->clk), "failed to get adc clock\n"); + /* + * Use a default value for the converter clock. + * This may become user-configurable in the future. + */ + ret = clk_set_rate(info->clk, info->data->clk_rate); + if (ret < 0) + return dev_err_probe(&pdev->dev, ret, + "failed to set adc clk rate\n"); platform_set_drvdata(pdev, indio_dev); -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: imu: st_lsm6dsx: fix possible lockup in" 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 iio: imu: st_lsm6dsx: fix possible lockup in 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 8114ef86e2058e2554111b793596f17bee23fa15 Mon Sep 17 00:00:00 2001 From: Silvano Seva <s.seva(a)4sigma.it> Date: Tue, 11 Mar 2025 09:49:49 +0100 Subject: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty. Fixes: 801a6e0af0c6 ("iio: imu: st_lsm6dsx: add support to LSM6DSO") Signed-off-by: Silvano Seva <s.seva(a)4sigma.it> Acked-by: Lorenzo Bianconi <lorenzo(a)kernel.org> Link: https://patch.msgid.link/20250311085030.3593-4-s.seva@4sigma.it Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c index 480a9b31065c..8a9d2593576a 100644 --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c @@ -626,6 +626,9 @@ int st_lsm6dsx_read_tagged_fifo(struct st_lsm6dsx_hw *hw) if (!fifo_len) return 0; + if (!pattern_len) + pattern_len = ST_LSM6DSX_TAGGED_SAMPLE_SIZE; + for (read_len = 0; read_len < fifo_len; read_len += pattern_len) { err = st_lsm6dsx_read_block(hw, ST_LSM6DSX_REG_FIFO_OUT_TAG_ADDR, -- 2.49.0

6 days, 20 hours

1
0
0 0

patch "iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo" 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 iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo 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 159ca7f18129834b6f4c7eae67de48e96c752fc9 Mon Sep 17 00:00:00 2001 From: Silvano Seva <s.seva(a)4sigma.it> Date: Tue, 11 Mar 2025 09:49:47 +0100 Subject: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty. Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Signed-off-by: Silvano Seva <s.seva(a)4sigma.it> Acked-by: Lorenzo Bianconi <lorenzo(a)kernel.org> Link: https://patch.msgid.link/20250311085030.3593-2-s.seva@4sigma.it Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c index 0a7cd8c1aa33..480a9b31065c 100644 --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c @@ -392,6 +392,9 @@ int st_lsm6dsx_read_fifo(struct st_lsm6dsx_hw *hw) if (fifo_status & cpu_to_le16(ST_LSM6DSX_FIFO_EMPTY_MASK)) return 0; + if (!pattern_len) + pattern_len = ST_LSM6DSX_SAMPLE_SIZE; + fifo_len = (le16_to_cpu(fifo_status) & fifo_diff_mask) * ST_LSM6DSX_CHAN_SIZE; fifo_len = (fifo_len / pattern_len) * pattern_len; -- 2.49.0

6 days, 20 hours

1
0
0 0

[PATCH v2] usb: dwc2: gadget: Fix enter to hibernation for UTMI+ PHY

by Minas Harutyunyan

For UTMI+ PHY, according to programming guide, first should be set PMUACTV bit then STOPPCLK bit. Otherwise, when the device issues Remote Wakeup, then host notices disconnect instead. For ULPI PHY, above mentioned bits must be set in reversed order: STOPPCLK then PMUACTV. Fixes: 4483ef3c1685 ("usb: dwc2: Add hibernation updates for ULPI PHY") Cc: stable(a)vger.kernel.org Reported-by: Tomasz Mon <tomasz.mon(a)nordicsemi.no> Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com> --- Changes in v2: - Added Cc: stable(a)vger.kernel.org --- drivers/usb/dwc2/gadget.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index e7bf9cc635be..be6b792e9a7d 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -5345,20 +5345,33 @@ int dwc2_gadget_enter_hibernation(struct dwc2_hsotg *hsotg) if (gusbcfg & GUSBCFG_ULPI_UTMI_SEL) { /* ULPI interface */ gpwrdn |= GPWRDN_ULPI_LATCH_EN_DURING_HIB_ENTRY; - } - dwc2_writel(hsotg, gpwrdn, GPWRDN); - udelay(10); + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); - /* Suspend the Phy Clock */ - pcgcctl = dwc2_readl(hsotg, PCGCTL); - pcgcctl |= PCGCTL_STOPPCLK; - dwc2_writel(hsotg, pcgcctl, PCGCTL); - udelay(10); + pcgcctl = dwc2_readl(hsotg, PCGCTL); + pcgcctl |= PCGCTL_STOPPCLK; + dwc2_writel(hsotg, pcgcctl, PCGCTL); + udelay(10); - gpwrdn = dwc2_readl(hsotg, GPWRDN); - gpwrdn |= GPWRDN_PMUACTV; - dwc2_writel(hsotg, gpwrdn, GPWRDN); - udelay(10); + gpwrdn = dwc2_readl(hsotg, GPWRDN); + gpwrdn |= GPWRDN_PMUACTV; + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); + } else { + /* UTMI+ Interface */ + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); + + gpwrdn = dwc2_readl(hsotg, GPWRDN); + gpwrdn |= GPWRDN_PMUACTV; + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); + + pcgcctl = dwc2_readl(hsotg, PCGCTL); + pcgcctl |= PCGCTL_STOPPCLK; + dwc2_writel(hsotg, pcgcctl, PCGCTL); + udelay(10); + } /* Set flag to indicate that we are in hibernation */ hsotg->hibernated = 1; base-commit: 12393996c1b28cd944465d2f55500ca84399a7f1 -- 2.41.0

6 days, 20 hours

2
1
0 0

[PATCH 0/3 V3] usb: usbtmc: Fix erroneous ioctl returns

by Dave Penkler

Recent tests with timeouts > INT_MAX produced random error returns with usbtmc_get_stb. This was caused by assigning the return value of wait_event_interruptible_timeout to an int which overflowed to negative values. Also return value on success was the remaining number of jiffies instead of 0. These patches fix all the cases where the return of wait_event_interruptible_timeout was assigned to an int and the case of the remaining jiffies return in usbtmc_get_stb. Patch 1: Fixes usbtmc_get_stb Patch 2: Fixes usbtmc488_ioctl_wait_srq Patch 3: Fixes usbtmc_generic_read Dave Penkler (3): usb: usbtmc: Fix erroneous get_stb ioctl error returns usb: usbtmc: Fix erroneous wait_srq ioctl return usb: usbtmc: Fix erroneous generic_read ioctl return drivers/usb/class/usbtmc.c | 53 ++++++++++++++++++++++---------------- 1 file changed, 31 insertions(+), 22 deletions(-) -- Changes V1 => V2 Add cc to stable line V2 => V3 Add susbsystem to cover letter 2.49.0

6 days, 21 hours

2
1
0 0

FAILED: patch "[PATCH] drm/amd/display: Default IPS to RCG_IN_ACTIVE_IPS2_IN_OFF" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 6ed0dc3fd39558f48119daf8f99f835deb7d68da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042838-flinch-defeat-6a51@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6ed0dc3fd39558f48119daf8f99f835deb7d68da Mon Sep 17 00:00:00 2001 From: Leo Li <sunpeng.li(a)amd.com> Date: Tue, 18 Mar 2025 18:05:05 -0400 Subject: [PATCH] drm/amd/display: Default IPS to RCG_IN_ACTIVE_IPS2_IN_OFF [Why] Recent findings show negligible power savings between IPS2 and RCG during static desktop. In fact, DCN related clocks are higher when IPS2 is enabled vs RCG. RCG_IN_ACTIVE is also the default policy for another OS supported by DC, and it has faster entry/exit. [How] Remove previous logic that checked for IPS2 support, and just default to `DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF`. Fixes: 199888aa25b3 ("drm/amd/display: Update IPS default mode for DCN35/DCN351") Reviewed-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Leo Li <sunpeng.li(a)amd.com> Signed-off-by: Zaeem Mohamed <zaeem.mohamed(a)amd.com> Tested-by: Mark Broadworth <mark.broadworth(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 8f772d79ef39b463ead00ef6f009bebada3a9d49) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 61ee530d78ea..5fe0b4921568 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1920,26 +1920,6 @@ static enum dmub_ips_disable_type dm_get_default_ips_mode( switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) { case IP_VERSION(3, 5, 0): case IP_VERSION(3, 6, 0): - /* - * On DCN35 systems with Z8 enabled, it's possible for IPS2 + Z8 to - * cause a hard hang. A fix exists for newer PMFW. - * - * As a workaround, for non-fixed PMFW, force IPS1+RCG as the deepest - * IPS state in all cases, except for s0ix and all displays off (DPMS), - * where IPS2 is allowed. - * - * When checking pmfw version, use the major and minor only. - */ - if ((adev->pm.fw_version & 0x00FFFF00) < 0x005D6300) - ret = DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF; - else if (amdgpu_ip_version(adev, GC_HWIP, 0) > IP_VERSION(11, 5, 0)) - /* - * Other ASICs with DCN35 that have residency issues with - * IPS2 in idle. - * We want them to use IPS2 only in display off cases. - */ - ret = DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF; - break; case IP_VERSION(3, 5, 1): ret = DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF; break;

6 days, 21 hours

2
1
0 0

FAILED: patch "[PATCH] drm/amd/display: Default IPS to RCG_IN_ACTIVE_IPS2_IN_OFF" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x 6ed0dc3fd39558f48119daf8f99f835deb7d68da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042837-embellish-dragging-2996@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6ed0dc3fd39558f48119daf8f99f835deb7d68da Mon Sep 17 00:00:00 2001 From: Leo Li <sunpeng.li(a)amd.com> Date: Tue, 18 Mar 2025 18:05:05 -0400 Subject: [PATCH] drm/amd/display: Default IPS to RCG_IN_ACTIVE_IPS2_IN_OFF [Why] Recent findings show negligible power savings between IPS2 and RCG during static desktop. In fact, DCN related clocks are higher when IPS2 is enabled vs RCG. RCG_IN_ACTIVE is also the default policy for another OS supported by DC, and it has faster entry/exit. [How] Remove previous logic that checked for IPS2 support, and just default to `DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF`. Fixes: 199888aa25b3 ("drm/amd/display: Update IPS default mode for DCN35/DCN351") Reviewed-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Leo Li <sunpeng.li(a)amd.com> Signed-off-by: Zaeem Mohamed <zaeem.mohamed(a)amd.com> Tested-by: Mark Broadworth <mark.broadworth(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 8f772d79ef39b463ead00ef6f009bebada3a9d49) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 61ee530d78ea..5fe0b4921568 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1920,26 +1920,6 @@ static enum dmub_ips_disable_type dm_get_default_ips_mode( switch (amdgpu_ip_version(adev, DCE_HWIP, 0)) { case IP_VERSION(3, 5, 0): case IP_VERSION(3, 6, 0): - /* - * On DCN35 systems with Z8 enabled, it's possible for IPS2 + Z8 to - * cause a hard hang. A fix exists for newer PMFW. - * - * As a workaround, for non-fixed PMFW, force IPS1+RCG as the deepest - * IPS state in all cases, except for s0ix and all displays off (DPMS), - * where IPS2 is allowed. - * - * When checking pmfw version, use the major and minor only. - */ - if ((adev->pm.fw_version & 0x00FFFF00) < 0x005D6300) - ret = DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF; - else if (amdgpu_ip_version(adev, GC_HWIP, 0) > IP_VERSION(11, 5, 0)) - /* - * Other ASICs with DCN35 that have residency issues with - * IPS2 in idle. - * We want them to use IPS2 only in display off cases. - */ - ret = DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF; - break; case IP_VERSION(3, 5, 1): ret = DMUB_IPS_RCG_IN_ACTIVE_IPS2_IN_OFF; break;

6 days, 21 hours

2
1
0 0

[PATCH v4 6.6] iommu: Handle race with default domain setup

by Robin Murphy

[ Upstream commit b46064a18810bad3aea089a79993ca5ea7a3d2b2 ] It turns out that deferred default domain creation leaves a subtle race window during iommu_device_register() wherein a client driver may asynchronously probe in parallel and get as far as performing DMA API operations with dma-direct, only to be switched to iommu-dma underfoot once the default domain attachment finally happens, with obviously disastrous consequences. Even the wonky of_iommu_configure() path is at risk, since iommu_fwspec_init() will no longer defer client probe as the instance ops are (necessarily) already registered, and the "replay" iommu_probe_device() call can see dev->iommu_group already set and so think there's nothing to do either. Fortunately we already have the right tool in the right place in the form of iommu_device_use_default_domain(), which just needs to ensure that said default domain is actually ready to *be* used. Deferring the client probe shouldn't have too much impact, given that this only happens while the IOMMU driver is probing, and thus due to kick the deferred probe list again once it finishes. [ Backport: The above is true for mainline, but here we still have arch_setup_dma_ops() to worry about, which is not replayed if the default domain happens to be allocated *between* that call and subsequently reaching iommu_device_use_default_domain(), so we need an additional earlier check to cover that case. Also we're now back before the nominal commit 98ac73f99bc4 so we need to tweak the logic to depend on IOMMU_DMA as well, to avoid falsely deferring on architectures not using default domains (but also tegra-smmu, which we can identify via set_platform_dma). This then serves us back as far as f188056352bc, where this specific form of the problem first arises. ] Reported-by: Charan Teja Kalla <quic_charante(a)quicinc.com> Fixes: 98ac73f99bc4 ("iommu: Require a default_domain for all iommu drivers") Fixes: f188056352bc ("iommu: Avoid locking/unlocking for iommu_probe_device()") Link: https://lore.kernel.org/r/e88b94c9b575034a2c98a48b3d383654cbda7902.17407532… Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- OK, c8cc2655cc6c might cherry-pick, but I really should have tried building it first... -EMORECOFFEE Trying again, I think this should work for Tegra without being disruptive to anything else. drivers/iommu/iommu.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 3f1029c0825e..f2b3a4e2e54f 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -566,6 +566,18 @@ int iommu_probe_device(struct device *dev) mutex_lock(&iommu_probe_device_lock); ret = __iommu_probe_device(dev, NULL); mutex_unlock(&iommu_probe_device_lock); + + /* + * The dma_configure replay paths need bus_iommu_probe() to + * finish before they can call arch_setup_dma_ops() + */ + if (IS_ENABLED(CONFIG_IOMMU_DMA) && !ret && dev->iommu_group) { + mutex_lock(&dev->iommu_group->mutex); + if (!dev->iommu_group->default_domain && + !dev_iommu_ops(dev)->set_platform_dma_ops) + ret = -EPROBE_DEFER; + mutex_unlock(&dev->iommu_group->mutex); + } if (ret) return ret; @@ -3149,6 +3161,12 @@ int iommu_device_use_default_domain(struct device *dev) return 0; mutex_lock(&group->mutex); + /* We may race against bus_iommu_probe() finalising groups here */ + if (IS_ENABLED(CONFIG_IOMMU_DMA) && !group->default_domain && + !dev_iommu_ops(dev)->set_platform_dma_ops) { + ret = -EPROBE_DEFER; + goto unlock_out; + } if (group->owner_cnt) { if (group->owner || !iommu_is_default_domain(group) || !xa_empty(&group->pasid_array)) { -- 2.39.2.101.g768bb238c484.dirty

1 week

1
0
0 0

[PATCH v3 6.6] iommu: Handle race with default domain setup

by Robin Murphy

[ Upstream commit b46064a18810bad3aea089a79993ca5ea7a3d2b2 ] It turns out that deferred default domain creation leaves a subtle race window during iommu_device_register() wherein a client driver may asynchronously probe in parallel and get as far as performing DMA API operations with dma-direct, only to be switched to iommu-dma underfoot once the default domain attachment finally happens, with obviously disastrous consequences. Even the wonky of_iommu_configure() path is at risk, since iommu_fwspec_init() will no longer defer client probe as the instance ops are (necessarily) already registered, and the "replay" iommu_probe_device() call can see dev->iommu_group already set and so think there's nothing to do either. Fortunately we already have the right tool in the right place in the form of iommu_device_use_default_domain(), which just needs to ensure that said default domain is actually ready to *be* used. Deferring the client probe shouldn't have too much impact, given that this only happens while the IOMMU driver is probing, and thus due to kick the deferred probe list again once it finishes. [ Backport: The above is true for mainline, but here we still have arch_setup_dma_ops() to worry about, which is not replayed if the default domain happens to be allocated *between* that call and subsequently reaching iommu_device_use_default_domain(), so we need an additional earlier check to cover that case. Also we're now back before the nominal commit 98ac73f99bc4 so we need to tweak the logic to depend on IOMMU_DMA as well, to avoid falsely deferring on architectures not using default domains. This then serves us back as far as f188056352bc, where this specific form of the problem first arises. ] Reported-by: Charan Teja Kalla <quic_charante(a)quicinc.com> Fixes: 98ac73f99bc4 ("iommu: Require a default_domain for all iommu drivers") Fixes: f188056352bc ("iommu: Avoid locking/unlocking for iommu_probe_device()") Link: https://lore.kernel.org/r/e88b94c9b575034a2c98a48b3d383654cbda7902.17407532… Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- Resending as a new version with a new Message-Id so as not to confuse the tools... 6.12.y should simply have a straight cherry-pick of the mainline commit - 98ac73f99bc4 was in 6.7 so I'm not sure why autosel hasn't picked that already? Thanks, Robin. drivers/iommu/iommu.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 3f1029c0825e..713f2be48075 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -566,6 +566,17 @@ int iommu_probe_device(struct device *dev) mutex_lock(&iommu_probe_device_lock); ret = __iommu_probe_device(dev, NULL); mutex_unlock(&iommu_probe_device_lock); + + /* + * The dma_configure replay paths need bus_iommu_probe() to + * finish before they can call arch_setup_dma_ops() + */ + if (IS_ENABLED(CONFIG_IOMMU_DMA) && !ret && dev->iommu_group) { + mutex_lock(&dev->iommu_group->mutex); + if (!dev->iommu_group->default_domain) + ret = -EPROBE_DEFER; + mutex_unlock(&dev->iommu_group->mutex); + } if (ret) return ret; @@ -3149,6 +3160,11 @@ int iommu_device_use_default_domain(struct device *dev) return 0; mutex_lock(&group->mutex); + /* We may race against bus_iommu_probe() finalising groups here */ + if (IS_ENABLED(CONFIG_IOMMU_DMA) && !group->default_domain) { + ret = -EPROBE_DEFER; + goto unlock_out; + } if (group->owner_cnt) { if (group->owner || !iommu_is_default_domain(group) || !xa_empty(&group->pasid_array)) { -- 2.39.2.101.g768bb238c484.dirty

1 week

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025