- Linux-stable-mirror - lists.linaro.org

[PATCH v2 0/8] binder: several fixes for frozen notification

by Carlos Llamas

These are all fixes for the frozen notification patch [1], which as of today hasn't landed in mainline yet. As such, this patchset is rebased on top of the char-misc-next branch. [1] https://lore.kernel.org/all/20240709070047.4055369-2-yutingtseng@google.com/ Cc: stable(a)vger.kernel.org Cc: Yu-Ting Tseng <yutingtseng(a)google.com> Cc: Alice Ryhl <aliceryhl(a)google.com> Cc: Todd Kjos <tkjos(a)google.com> Cc: Martijn Coenen <maco(a)google.com> Cc: Arve Hjønnevåg <arve(a)android.com> Cc: Viktor Martensson <vmartensson(a)google.com> v1: https://lore.kernel.org/all/20240924184401.76043-1-cmllamas@google.com/ v2: * debug output for BINDER_WORK_CLEAR_FREEZE_NOTIFICATION (Alice) * allow notifications for dead nodes instead of EINVAL (Alice) * add fix for memleak of proc->delivered_freeze * add proc->delivered_freeze to debug output * collect tags Carlos Llamas (8): binder: fix node UAF in binder_add_freeze_work() binder: fix OOB in binder_add_freeze_work() binder: fix freeze UAF in binder_release_work() binder: fix BINDER_WORK_FROZEN_BINDER debug logs binder: fix BINDER_WORK_CLEAR_FREEZE_NOTIFICATION debug logs binder: allow freeze notification for dead nodes binder: fix memleak of proc->delivered_freeze binder: add delivered_freeze to debugfs output drivers/android/binder.c | 64 ++++++++++++++++++++++++++++++---------- 1 file changed, 49 insertions(+), 15 deletions(-) -- 2.46.1.824.gd892dcdcdd-goog

1 week, 5 days

4
23
0 0

[PATCH 5.15.y 0/2] Backport fix for CVE-2024-38538

by Sherry Yang

The 2nd patch fixes CVE-2024-38538, but it requires the helper function pskb_may_pull_reason which is defined in the 1st patch. Backport both together. Eric Dumazet (1): net: add pskb_may_pull_reason() helper Nikolay Aleksandrov (1): net: bridge: xmit: make sure we have at least eth header len bytes include/linux/skbuff.h | 19 +++++++++++++++---- net/bridge/br_device.c | 6 ++++++ 2 files changed, 21 insertions(+), 4 deletions(-) -- 2.46.0

1 week, 5 days

2
4
0 0

Dell WD19TB Thunderbolt Dock not working with kernel > 6.6.28-1

by Fabian Stäber

Hi, I got a Dell WD19TBS Thunderbolt Dock, and it has been working with Linux for years without issues. However, updating to linux-lts-6.6.29-1 or newer breaks the USB ports on my Dock. Using the latest non-LTS kernel doesn't help, it also breaks the USB ports. Downgrading the kernel to linux-lts-6.6.28-1 works. This is the last working version. I opened a thread on the Arch Linux forum https://bbs.archlinux.org/viewtopic.php?id=299604 with some dmesg output. However, it sounds like this is a regression in the Linux kernel, so I'm posting this here as well. Let me know if you need any more info. Thanks a lot Fabian

1 week, 5 days

6
7
0 0

[PATCH 5.15 0/3] Fix block integrity violation of kobject rules

by Thadeu Lima de Souza Cascardo

integrity_kobj did not have a release function and with CONFIG_DEBUG_KOBJECT_RELEASE, a use-after-free would be triggered as its holding struct gendisk would be freed without relying on its refcount. Thomas Weißschuh (3): blk-integrity: use sysfs_emit blk-integrity: convert to struct device_attribute blk-integrity: register sysfs attributes on struct device block/blk-integrity.c | 175 ++++++++++++++--------------------------- block/blk.h | 10 +-- block/genhd.c | 12 +-- include/linux/blkdev.h | 3 - 4 files changed, 66 insertions(+), 134 deletions(-) -- 2.34.1

1 week, 5 days

1
3
0 0

Re: [PATCH 6.11 000/558] 6.11.3-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

1 week, 5 days

1
0
0 0

[tip: irq/urgent] irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

by tip-bot2 for Marc Zyngier

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 1442ee0011983f0c5c4b92380e6853afb513841a Gitweb: https://git.kernel.org/tip/1442ee0011983f0c5c4b92380e6853afb513841a Author: Marc Zyngier <maz(a)kernel.org> AuthorDate: Wed, 02 Oct 2024 21:49:59 +01:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Tue, 08 Oct 2024 17:44:27 +02:00 irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP") Reported-by: Kunkun Jiang <jiangkunkun(a)huawei.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/c182ece6-2ba0-ce4f-3404-dba7a3ab6c52@huawei.com Link: https://lore.kernel.org/all/20241002204959.2051709-1-maz@kernel.org --- drivers/irqchip/irq-gic-v3-its.c | 18 ++++++++++++------ include/linux/irqchip/arm-gic-v4.h | 4 +++- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index fdec478..ab597e7 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -797,8 +797,8 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its, its_encode_valid(cmd, desc->its_vmapp_cmd.valid); if (!desc->its_vmapp_cmd.valid) { + alloc = !atomic_dec_return(&desc->its_vmapp_cmd.vpe->vmapp_count); if (is_v4_1(its)) { - alloc = !atomic_dec_return(&desc->its_vmapp_cmd.vpe->vmapp_count); its_encode_alloc(cmd, alloc); /* * Unmapping a VPE is self-synchronizing on GICv4.1, @@ -817,13 +817,13 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its, its_encode_vpt_addr(cmd, vpt_addr); its_encode_vpt_size(cmd, LPI_NRBITS - 1); + alloc = !atomic_fetch_inc(&desc->its_vmapp_cmd.vpe->vmapp_count); + if (!is_v4_1(its)) goto out; vconf_addr = virt_to_phys(page_address(desc->its_vmapp_cmd.vpe->its_vm->vprop_page)); - alloc = !atomic_fetch_inc(&desc->its_vmapp_cmd.vpe->vmapp_count); - its_encode_alloc(cmd, alloc); /* @@ -3807,6 +3807,13 @@ static int its_vpe_set_affinity(struct irq_data *d, unsigned long flags; /* + * Check if we're racing against a VPE being destroyed, for + * which we don't want to allow a VMOVP. + */ + if (!atomic_read(&vpe->vmapp_count)) + return -EINVAL; + + /* * Changing affinity is mega expensive, so let's be as lazy as * we can and only do it if we really have to. Also, if mapped * into the proxy device, we need to move the doorbell @@ -4463,9 +4470,8 @@ static int its_vpe_init(struct its_vpe *vpe) raw_spin_lock_init(&vpe->vpe_lock); vpe->vpe_id = vpe_id; vpe->vpt_page = vpt_page; - if (gic_rdists->has_rvpeid) - atomic_set(&vpe->vmapp_count, 0); - else + atomic_set(&vpe->vmapp_count, 0); + if (!gic_rdists->has_rvpeid) vpe->vpe_proxy_event = -1; return 0; diff --git a/include/linux/irqchip/arm-gic-v4.h b/include/linux/irqchip/arm-gic-v4.h index ecabed6..7f1f11a 100644 --- a/include/linux/irqchip/arm-gic-v4.h +++ b/include/linux/irqchip/arm-gic-v4.h @@ -66,10 +66,12 @@ struct its_vpe { bool enabled; bool group; } sgi_config[16]; - atomic_t vmapp_count; }; }; + /* Track the VPE being mapped */ + atomic_t vmapp_count; + /* * Ensures mutual exclusion between affinity setting of the * vPE and vLPI operations using vpe->col_idx.

1 week, 5 days

1
0
0 0

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

by Nam Cao

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

1 week, 5 days

2
1
0 0

FAILED: patch "[PATCH] drm/xe/vm: move xa_alloc to prevent UAF" failed to apply to 6.11-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.11-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.11.y git checkout FETCH_HEAD git cherry-pick -x 74231870cf4976f69e83aa24f48edb16619f652f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100727-compacted-armored-bbce@gregkh' --subject-prefix 'PATCH 6.11.y' HEAD^.. Possible dependencies: 74231870cf49 ("drm/xe/vm: move xa_alloc to prevent UAF") 9e3c85ddea7a ("drm/xe: Clean up VM / exec queue file lock usage.") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 74231870cf4976f69e83aa24f48edb16619f652f Mon Sep 17 00:00:00 2001 From: Matthew Auld <matthew.auld(a)intel.com> Date: Wed, 25 Sep 2024 08:14:27 +0100 Subject: [PATCH] drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ Reviewed-by: Nirmoy Das <nirmoy.das(a)intel.com> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240925071426.144015-3-matth… (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9) Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 31fe31db3fdc..ce9dca4d4e87 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -1765,10 +1765,6 @@ int xe_vm_create_ioctl(struct drm_device *dev, void *data, if (IS_ERR(vm)) return PTR_ERR(vm); - err = xa_alloc(&xef->vm.xa, &id, vm, xa_limit_32b, GFP_KERNEL); - if (err) - goto err_close_and_put; - if (xe->info.has_asid) { down_write(&xe->usm.lock); err = xa_alloc_cyclic(&xe->usm.asid_to_vm, &asid, vm, @@ -1776,12 +1772,11 @@ int xe_vm_create_ioctl(struct drm_device *dev, void *data, &xe->usm.next_asid, GFP_KERNEL); up_write(&xe->usm.lock); if (err < 0) - goto err_free_id; + goto err_close_and_put; vm->usm.asid = asid; } - args->vm_id = id; vm->xef = xe_file_get(xef); /* Record BO memory for VM pagetable created against client */ @@ -1794,10 +1789,15 @@ int xe_vm_create_ioctl(struct drm_device *dev, void *data, args->reserved[0] = xe_bo_main_addr(vm->pt_root[0]->bo, XE_PAGE_SIZE); #endif + /* user id alloc must always be last in ioctl to prevent UAF */ + err = xa_alloc(&xef->vm.xa, &id, vm, xa_limit_32b, GFP_KERNEL); + if (err) + goto err_close_and_put; + + args->vm_id = id; + return 0; -err_free_id: - xa_erase(&xef->vm.xa, id); err_close_and_put: xe_vm_close_and_put(vm);

1 week, 5 days

3
2
0 0

+ mm-mremap-prevent-racing-change-of-old-pmd-type.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/mremap: prevent racing change of old pmd type has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-mremap-prevent-racing-change-of-old-pmd-type.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: Jann Horn <jannh(a)google.com> Subject: mm/mremap: prevent racing change of old pmd type Date: Wed, 02 Oct 2024 23:07:06 +0200 Prevent move_normal_pmd() in mremap() from racing with retract_page_tables() in MADVISE_COLLAPSE such that pmd_populate(mm, new_pmd, pmd_pgtable(pmd)) operates on an empty source pmd, causing creation of a new pmd which maps physical address 0 as a page table. This bug is only reachable if either CONFIG_READ_ONLY_THP_FOR_FS is set or THP shmem is usable. (Unprivileged namespaces can be used to set up a tmpfs that can contain THP shmem pages with "huge=advise".) If userspace triggers this bug *in multiple processes*, this could likely be used to create stale TLB entries pointing to freed pages or cause kernel UAF by breaking an invariant the rmap code relies on. Fix it by moving the rmap locking up so that it covers the span from reading the PMD entry to moving the page table. Link: https://lkml.kernel.org/r/20241002-move_normal_pmd-vs-collapse-fix-v1-1-782… Fixes: 1d65b771bc08 ("mm/khugepaged: retract_page_tables() without mmap or vma lock") Signed-off-by: Jann Horn <jannh(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mremap.c | 68 +++++++++++++++++++++++++++----------------------- 1 file changed, 38 insertions(+), 30 deletions(-) --- a/mm/mremap.c~mm-mremap-prevent-racing-change-of-old-pmd-type +++ a/mm/mremap.c @@ -136,17 +136,17 @@ static pte_t move_soft_dirty_pte(pte_t p static int move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd, unsigned long old_addr, unsigned long old_end, struct vm_area_struct *new_vma, pmd_t *new_pmd, - unsigned long new_addr, bool need_rmap_locks) + unsigned long new_addr) { struct mm_struct *mm = vma->vm_mm; pte_t *old_pte, *new_pte, pte; spinlock_t *old_ptl, *new_ptl; bool force_flush = false; unsigned long len = old_end - old_addr; - int err = 0; /* - * When need_rmap_locks is true, we take the i_mmap_rwsem and anon_vma + * When need_rmap_locks is true in the caller, we are holding the + * i_mmap_rwsem and anon_vma * locks to ensure that rmap will always observe either the old or the * new ptes. This is the easiest way to avoid races with * truncate_pagecache(), page migration, etc... @@ -163,23 +163,18 @@ static int move_ptes(struct vm_area_stru * serialize access to individual ptes, but only rmap traversal * order guarantees that we won't miss both the old and new ptes). */ - if (need_rmap_locks) - take_rmap_locks(vma); /* * We don't have to worry about the ordering of src and dst * pte locks because exclusive mmap_lock prevents deadlock. */ old_pte = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl); - if (!old_pte) { - err = -EAGAIN; - goto out; - } + if (!old_pte) + return -EAGAIN; new_pte = pte_offset_map_nolock(mm, new_pmd, new_addr, &new_ptl); if (!new_pte) { pte_unmap_unlock(old_pte, old_ptl); - err = -EAGAIN; - goto out; + return -EAGAIN; } if (new_ptl != old_ptl) spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING); @@ -217,10 +212,7 @@ static int move_ptes(struct vm_area_stru spin_unlock(new_ptl); pte_unmap(new_pte - 1); pte_unmap_unlock(old_pte - 1, old_ptl); -out: - if (need_rmap_locks) - drop_rmap_locks(vma); - return err; + return 0; } #ifndef arch_supports_page_table_move @@ -447,17 +439,14 @@ static __always_inline unsigned long get /* * Attempts to speedup the move by moving entry at the level corresponding to * pgt_entry. Returns true if the move was successful, else false. + * rmap locks are held by the caller. */ static bool move_pgt_entry(enum pgt_entry entry, struct vm_area_struct *vma, unsigned long old_addr, unsigned long new_addr, - void *old_entry, void *new_entry, bool need_rmap_locks) + void *old_entry, void *new_entry) { bool moved = false; - /* See comment in move_ptes() */ - if (need_rmap_locks) - take_rmap_locks(vma); - switch (entry) { case NORMAL_PMD: moved = move_normal_pmd(vma, old_addr, new_addr, old_entry, @@ -483,9 +472,6 @@ static bool move_pgt_entry(enum pgt_entr break; } - if (need_rmap_locks) - drop_rmap_locks(vma); - return moved; } @@ -550,6 +536,7 @@ unsigned long move_page_tables(struct vm struct mmu_notifier_range range; pmd_t *old_pmd, *new_pmd; pud_t *old_pud, *new_pud; + int move_res; if (!len) return 0; @@ -573,6 +560,12 @@ unsigned long move_page_tables(struct vm old_addr, old_end); mmu_notifier_invalidate_range_start(&range); + /* + * Hold rmap locks to ensure the type of the old PUD/PMD entry doesn't + * change under us due to khugepaged or folio splitting. + */ + take_rmap_locks(vma); + for (; old_addr < old_end; old_addr += extent, new_addr += extent) { cond_resched(); /* @@ -590,14 +583,14 @@ unsigned long move_page_tables(struct vm if (pud_trans_huge(*old_pud) || pud_devmap(*old_pud)) { if (extent == HPAGE_PUD_SIZE) { move_pgt_entry(HPAGE_PUD, vma, old_addr, new_addr, - old_pud, new_pud, need_rmap_locks); + old_pud, new_pud); /* We ignore and continue on error? */ continue; } } else if (IS_ENABLED(CONFIG_HAVE_MOVE_PUD) && extent == PUD_SIZE) { if (move_pgt_entry(NORMAL_PUD, vma, old_addr, new_addr, - old_pud, new_pud, true)) + old_pud, new_pud)) continue; } @@ -613,7 +606,7 @@ again: pmd_devmap(*old_pmd)) { if (extent == HPAGE_PMD_SIZE && move_pgt_entry(HPAGE_PMD, vma, old_addr, new_addr, - old_pmd, new_pmd, need_rmap_locks)) + old_pmd, new_pmd)) continue; split_huge_pmd(vma, old_pmd, old_addr); } else if (IS_ENABLED(CONFIG_HAVE_MOVE_PMD) && @@ -623,17 +616,32 @@ again: * moving at the PMD level if possible. */ if (move_pgt_entry(NORMAL_PMD, vma, old_addr, new_addr, - old_pmd, new_pmd, true)) + old_pmd, new_pmd)) continue; } if (pmd_none(*old_pmd)) continue; - if (pte_alloc(new_vma->vm_mm, new_pmd)) + + /* + * Temporarily drop the rmap locks while we do a potentially + * slow move_ptes() operation, unless move_ptes() wants them + * held (see comment inside there). + */ + if (!need_rmap_locks) + drop_rmap_locks(vma); + if (pte_alloc(new_vma->vm_mm, new_pmd)) { + if (!need_rmap_locks) + take_rmap_locks(vma); break; - if (move_ptes(vma, old_pmd, old_addr, old_addr + extent, - new_vma, new_pmd, new_addr, need_rmap_locks) < 0) + } + move_res = move_ptes(vma, old_pmd, old_addr, old_addr + extent, + new_vma, new_pmd, new_addr); + if (!need_rmap_locks) + take_rmap_locks(vma); + if (move_res < 0) goto again; } + drop_rmap_locks(vma); mmu_notifier_invalidate_range_end(&range); _ Patches currently in -mm which might be from jannh(a)google.com are mm-mremap-prevent-racing-change-of-old-pmd-type.patch

1 week, 5 days

3
2
0 0

[PATCH 00/15] media: stm32: introduction of CSI / DCMIPP for STM32MP25

by Alain Volmat

This series introduces the camera pipeline support for the STM32MP25 SOC. The STM32MP25 has 3 pipelines, fed from a single camera input which can be either parallel or csi. This series adds the basic support for the 1st pipe (dump) which, in term of features is same as the one featured on the STM32MP13 SOC. It focuses on introduction of the CSI input stage for the DCMIPP, and the CSI specific new control code for the DCMIPP. One of the subdev of the DCMIPP, dcmipp_parallel is now renamed as dcmipp_input since it allows to not only control the parallel but also the csi interface. Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> --- Alain Volmat (15): media: stm32: dcmipp: correct dma_set_mask_and_coherent mask value dt-bindings: media: addition of stm32 csi driver description media: stm32: csi: addition of the STM32 CSI driver media: stm32: dcmipp: use v4l2_subdev_is_streaming media: stm32: dcmipp: replace s_stream with enable/disable_streams media: stm32: dcmipp: rename dcmipp_parallel into dcmipp_input media: stm32: dcmipp: add support for csi input into dcmipp-input media: stm32: dcmipp: add bayer 10~14 bits formats media: stm32: dcmipp: add 1X16 RGB / YUV formats support media: stm32: dcmipp: avoid duplicated format on enum in bytecap media: stm32: dcmipp: fill media ctl hw_revision field dt-bindings: media: addition of stm32mp25 compatible of DCMIPP media: stm32: dcmipp: add core support for the stm32mp25 arm64: dts: st: add csi & dcmipp node in stm32mp25 arm64: dts: st: enable imx335/csi/dcmipp pipeline on stm32mp257f-ev1 .../devicetree/bindings/media/st,stm32-csi.yaml | 129 +++ .../devicetree/bindings/media/st,stm32-dcmipp.yaml | 53 +- MAINTAINERS | 8 + arch/arm64/boot/dts/st/stm32mp251.dtsi | 23 + arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 87 ++ drivers/media/platform/st/stm32/Kconfig | 14 + drivers/media/platform/st/stm32/Makefile | 1 + drivers/media/platform/st/stm32/stm32-csi.c | 1150 ++++++++++++++++++++ .../media/platform/st/stm32/stm32-dcmipp/Makefile | 2 +- .../st/stm32/stm32-dcmipp/dcmipp-bytecap.c | 128 ++- .../st/stm32/stm32-dcmipp/dcmipp-byteproc.c | 119 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-common.h | 4 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-core.c | 116 +- .../platform/st/stm32/stm32-dcmipp/dcmipp-input.c | 540 +++++++++ .../st/stm32/stm32-dcmipp/dcmipp-parallel.c | 440 -------- 15 files changed, 2238 insertions(+), 576 deletions(-) --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20241007-csi_dcmipp_mp25-7779601f57da Best regards, -- Alain Volmat <alain.volmat(a)foss.st.com>

1 week, 5 days

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror