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 months, 1 week

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 months, 1 week

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 months, 1 week

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 months, 1 week

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 months, 1 week

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 months, 1 week

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 months, 1 week

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 months, 1 week

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 months, 1 week

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 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025