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

[PATCH] io_uring/rsrc: fix RLIMIT_MEMLOCK bypass via compound page accounting

by Yuhao Jiang

When multiple registered buffers share the same compound page, only the first buffer accounts for the memory via io_buffer_account_pin(). The subsequent buffers skip accounting since headpage_already_acct() returns true. When the first buffer is unregistered, the accounting is decremented, but the compound page remains pinned by the remaining buffers. This creates a state where pinned memory is not properly accounted against RLIMIT_MEMLOCK. On systems with HugeTLB pages pre-allocated, an unprivileged user can exploit this to pin memory beyond RLIMIT_MEMLOCK by cycling buffer registrations. The bypass amount is proportional to the number of available huge pages, potentially allowing gigabytes of memory to be pinned while the kernel accounting shows near-zero. Fix this by recalculating the actual pages to unaccount when unmapping a buffer. For regular pages, always unaccount. For compound pages, only unaccount if no other registered buffer references the same compound page. This ensures the accounting persists until the last buffer referencing the compound page is released. Reported-by: Yuhao Jiang <danisjiang(a)gmail.com> Fixes: 57bebf807e2a ("io_uring/rsrc: optimise registered huge pages") Cc: stable(a)vger.kernel.org Signed-off-by: Yuhao Jiang <danisjiang(a)gmail.com> --- io_uring/rsrc.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 2 deletions(-) diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c index a63474b331bf..dcf2340af5a2 100644 --- a/io_uring/rsrc.c +++ b/io_uring/rsrc.c @@ -139,15 +139,80 @@ static void io_free_imu(struct io_ring_ctx *ctx, struct io_mapped_ubuf *imu) kvfree(imu); } +/* + * Calculate pages to unaccount when unmapping a buffer. Regular pages are + * always counted. Compound pages are only counted if no other registered + * buffer references them, ensuring accounting persists until the last user. + */ +static unsigned long io_buffer_calc_unaccount(struct io_ring_ctx *ctx, + struct io_mapped_ubuf *imu) +{ + struct page *last_hpage = NULL; + unsigned long acct = 0; + unsigned int i; + + for (i = 0; i < imu->nr_bvecs; i++) { + struct page *page = imu->bvec[i].bv_page; + struct page *hpage; + unsigned int j; + + if (!PageCompound(page)) { + acct++; + continue; + } + + hpage = compound_head(page); + if (hpage == last_hpage) + continue; + last_hpage = hpage; + + /* Check if we already processed this hpage earlier in this buffer */ + for (j = 0; j < i; j++) { + if (PageCompound(imu->bvec[j].bv_page) && + compound_head(imu->bvec[j].bv_page) == hpage) + goto next_hpage; + } + + /* Only unaccount if no other buffer references this page */ + for (j = 0; j < ctx->buf_table.nr; j++) { + struct io_rsrc_node *node = ctx->buf_table.nodes[j]; + struct io_mapped_ubuf *other; + unsigned int k; + + if (!node) + continue; + other = node->buf; + if (other == imu) + continue; + + for (k = 0; k < other->nr_bvecs; k++) { + struct page *op = other->bvec[k].bv_page; + + if (!PageCompound(op)) + continue; + if (compound_head(op) == hpage) + goto next_hpage; + } + } + acct += page_size(hpage) >> PAGE_SHIFT; +next_hpage: + ; + } + return acct; +} + static void io_buffer_unmap(struct io_ring_ctx *ctx, struct io_mapped_ubuf *imu) { + unsigned long acct; + if (unlikely(refcount_read(&imu->refs) > 1)) { if (!refcount_dec_and_test(&imu->refs)) return; } - if (imu->acct_pages) - io_unaccount_mem(ctx->user, ctx->mm_account, imu->acct_pages); + acct = io_buffer_calc_unaccount(ctx, imu); + if (acct) + io_unaccount_mem(ctx->user, ctx->mm_account, acct); imu->release(imu->priv); io_free_imu(ctx, imu); } -- 2.34.1

8 hours, 36 minutes

1
0
0 0

[PATCH] exec: do not call sched_mm_cid_after_execve() on exec fail

by Jinchao Wang

sched_mm_cid_after_execve() is called from the failure path of bprm_execve(). At that point exec has not completed successfully, so updating the mm CID state is incorrect and can trigger a panic, as reported by syzbot. Remove the call from the exec failure path. #syz test Cc: stable(a)vger.kernel.org Reported-by: syzbot+9ca2c6e6b098bf5ae60a(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- fs/exec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index 9d5ebc9d15b0..9044a75d26ab 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1773,7 +1773,6 @@ static int bprm_execve(struct linux_binprm *bprm) if (bprm->point_of_no_return && !fatal_signal_pending(current)) force_fatal_sig(SIGSEGV); - sched_mm_cid_after_execve(current); rseq_force_update(); current->in_execve = 0; -- 2.43.0

8 hours, 50 minutes

2
1
0 0

[PATCH] ext4: xattr: fix wrong search.here in clone_block

by Jinchao Wang

syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1]. When xattr_find_entry() returns -ENODATA, search.here still points to the position after the last valid entry. ext4_xattr_block_set() clones the xattr block because the original block maybe shared and must not be modified in place. In the clone_block, search.here is recomputed unconditionally from the old offset, which may place it past search.first. This results in a negative reset size and an out-of-bounds memmove() in ext4_xattr_set_entry(). Fix this by initializing search.here correctly when search.not_found is set. [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1 Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set) Cc: stable(a)vger.kernel.org Reported-by: syzbot+f792df426ff0f5ceb8d1(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- fs/ext4/xattr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 2e02efbddaac..cc30abeb7f30 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode, goto cleanup; s->first = ENTRY(header(s->base)+1); header(s->base)->h_refcount = cpu_to_le32(1); - s->here = ENTRY(s->base + offset); + if (s->not_found) + s->here = s->first; + else + s->here = ENTRY(s->base + offset); s->end = s->base + bs->bh->b_size; /* -- 2.43.0

9 hours, 56 minutes

3
4
0 0

[PATCH v2] net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write

by Deepanshu Kartikey

A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex. The problematic lock order is: Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lock Thread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutex This creates a classic ABBA deadlock scenario. Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock. This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free. The similar lock ordering in nfc_register_device() (device_lock -> rfkill_global_mutex via rfkill_register) is safe because during registration the device is not yet in rfkill_list, so no concurrent rfkill operations can occur on this device. Fixes: 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") Cc: stable(a)vger.kernel.org Reported-by: syzbot+4ef89409a235d804c6c2(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=4ef89409a235d804c6c2 Link: https://lore.kernel.org/all/20251217054908.178907-1-kartikey406@gmail.com/T/ [v1] Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> --- v2: - Added explanation of why UAF is not possible - Added explanation of why nfc_register_device() is safe - Added Fixes and Cc: stable tags - Fixed blank line after variable declaration (kept it) --- net/nfc/core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/net/nfc/core.c b/net/nfc/core.c index ae1c842f9c64..82f023f37754 100644 --- a/net/nfc/core.c +++ b/net/nfc/core.c @@ -1154,6 +1154,7 @@ EXPORT_SYMBOL(nfc_register_device); void nfc_unregister_device(struct nfc_dev *dev) { int rc; + struct rfkill *rfk = NULL; pr_debug("dev_name=%s\n", dev_name(&dev->dev)); @@ -1164,13 +1165,17 @@ void nfc_unregister_device(struct nfc_dev *dev) device_lock(&dev->dev); if (dev->rfkill) { - rfkill_unregister(dev->rfkill); - rfkill_destroy(dev->rfkill); + rfk = dev->rfkill; dev->rfkill = NULL; } dev->shutting_down = true; device_unlock(&dev->dev); + if (rfk) { + rfkill_unregister(rfk); + rfkill_destroy(rfk); + } + if (dev->ops->check_presence) { timer_delete_sync(&dev->check_pres_timer); cancel_work_sync(&dev->check_pres_work); -- 2.43.0

10 hours, 12 minutes

1
0
0 0

Re: Patch "drm/xe: Enforce correct user fence signaling order using" has been added to the 6.18-stable tree

by Thomas Hellström

Hi, On Sat, 2025-12-13 at 04:38 -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/xe: Enforce correct user fence signaling order using > > to the 6.18-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-xe-enforce-correct-user-fence-signaling-order-us.patch > and it can be found in the queue-6.18 subdirectory. > > If you, or anyone else, feels it should not be added to the stable > tree, > please let <stable(a)vger.kernel.org> know about it. > > (Already replied to a similar email from GregKH) Please skip this patch. The patch looks already applied and appears to be the result of an incorrect merge resolution. Thanks, Thomas > > commit e0d6df858765e6228a87c8559ccbe6826a1a6fef > Author: Matthew Brost <matthew.brost(a)intel.com> > Date: Fri Oct 31 16:40:45 2025 -0700 > > drm/xe: Enforce correct user fence signaling order using > > [ Upstream commit adda4e855ab6409a3edaa585293f1f2069ab7299 ] > > Prevent application hangs caused by out-of-order fence signaling > when > user fences are attached. Use drm_syncobj (via dma-fence-chain) > to > guarantee that each user fence signals in order, regardless of > the > signaling order of the attached fences. Ensure user fence > writebacks to > user space occur in the correct sequence. > > v7: > - Skip drm_syncbj create of error (CI) > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for > Intel GPUs") > Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> > Reviewed-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > Link: > https://patch.msgid.link/20251031234050.3043507-2-matthew.brost@intel.com > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c > b/drivers/gpu/drm/xe/xe_exec_queue.c > index cb5f204c08ed6..a6efe4e8ab556 100644 > --- a/drivers/gpu/drm/xe/xe_exec_queue.c > +++ b/drivers/gpu/drm/xe/xe_exec_queue.c > @@ -344,6 +344,9 @@ void xe_exec_queue_destroy(struct kref *ref) > struct xe_exec_queue *q = container_of(ref, struct > xe_exec_queue, refcount); > struct xe_exec_queue *eq, *next; > > + if (q->ufence_syncobj) > + drm_syncobj_put(q->ufence_syncobj); > + > if (q->ufence_syncobj) > drm_syncobj_put(q->ufence_syncobj); >

12 hours, 19 minutes

1
0
0 0

[PATCH V1] arm64: dts: qcom: talos: Correct UFS clocks ordering

by Pradeep P V K

The current UFS clocks does not align with their respective names, causing the ref_clk to be set to an incorrect frequency as below, which results in command timeouts. ufshcd-qcom 1d84000.ufshc: invalid ref_clk setting = 300000000 This commit fixes the issue by properly reordering the UFS clocks to match their names. Fixes: ea172f61f4fd ("arm64: dts: qcom: qcs615: Fix up UFS clocks") Cc: stable(a)vger.kernel.org Signed-off-by: Pradeep P V K <pradeep.pragallapati(a)oss.qualcomm.com> --- arch/arm64/boot/dts/qcom/talos.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi index d1dbfa3bd81c..95d26e313622 100644 --- a/arch/arm64/boot/dts/qcom/talos.dtsi +++ b/arch/arm64/boot/dts/qcom/talos.dtsi @@ -1399,10 +1399,10 @@ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>, <&gcc GCC_UFS_PHY_AHB_CLK>, <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>, - <&gcc GCC_UFS_PHY_ICE_CORE_CLK>, <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>, - <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>; + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>, + <&gcc GCC_UFS_PHY_ICE_CORE_CLK>; clock-names = "core_clk", "bus_aggr_clk", "iface_clk", -- 2.17.1

12 hours, 29 minutes

3
2
0 0

[PATCH v2] rust: Add -fdiagnostics-show-context to bindgen_skip_c_flags

by Siddhesh Poyarekar

This got added with: 7454048db27d6 ("kbuild: Enable GCC diagnostic context for value-tracking warnings") but clang does not have this option, so avoid passing it to bindgen. Cc: stable(a)vger.kernel.org Fixes: 7454048db27d6 ("kbuild: Enable GCC diagnostic context for value-tracking warnings") Signed-off-by: Siddhesh Poyarekar <siddhesh(a)gotplt.org> --- rust/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/rust/Makefile b/rust/Makefile index 5d357dce1704..4dcc2eff51cb 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -383,6 +383,7 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \ -fno-inline-functions-called-once -fsanitize=bounds-strict \ -fstrict-flex-arrays=% -fmin-function-alignment=% \ -fzero-init-padding-bits=% -mno-fdpic \ + -fdiagnostics-show-context -fdiagnostics-show-context=% \ --param=% --param asan-% -fno-isolate-erroneous-paths-dereference # Derived from `scripts/Makefile.clang`. -- 2.52.0

12 hours, 55 minutes

1
0
0 0

[PATCH] drm/xe: Drop preempt-fences when destroying imported dma-bufs.

by Thomas Hellström

When imported dma-bufs are destroyed, TTM is not fully individualizing the dma-resv, but it *is* copying the fences that need to be waited for before declaring idle. So in the case where the bo->resv != bo->_resv we can still drop the preempt-fences, but make sure we do that on bo->_resv which contains the fence-pointer copy. In the case where the copying fails, bo->_resv will typically not contain any fences pointers at all, so there will be nothing to drop. In that case, TTM would have ensured all fences that would have been copied are signaled, including any remaining preempt fences. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/xe/xe_bo.c | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c index 6280e6a013ff..8b6474cd3eaf 100644 --- a/drivers/gpu/drm/xe/xe_bo.c +++ b/drivers/gpu/drm/xe/xe_bo.c @@ -1526,7 +1526,7 @@ static bool xe_ttm_bo_lock_in_destructor(struct ttm_buffer_object *ttm_bo) * always succeed here, as long as we hold the lru lock. */ spin_lock(&ttm_bo->bdev->lru_lock); - locked = dma_resv_trylock(ttm_bo->base.resv); + locked = dma_resv_trylock(&ttm_bo->base._resv); spin_unlock(&ttm_bo->bdev->lru_lock); xe_assert(xe, locked); @@ -1546,13 +1546,6 @@ static void xe_ttm_bo_release_notify(struct ttm_buffer_object *ttm_bo) bo = ttm_to_xe_bo(ttm_bo); xe_assert(xe_bo_device(bo), !(bo->created && kref_read(&ttm_bo->base.refcount))); - /* - * Corner case where TTM fails to allocate memory and this BOs resv - * still points the VMs resv - */ - if (ttm_bo->base.resv != &ttm_bo->base._resv) - return; - if (!xe_ttm_bo_lock_in_destructor(ttm_bo)) return; @@ -1562,14 +1555,14 @@ static void xe_ttm_bo_release_notify(struct ttm_buffer_object *ttm_bo) * TODO: Don't do this for external bos once we scrub them after * unbind. */ - dma_resv_for_each_fence(&cursor, ttm_bo->base.resv, + dma_resv_for_each_fence(&cursor, &ttm_bo->base._resv, DMA_RESV_USAGE_BOOKKEEP, fence) { if (xe_fence_is_xe_preempt(fence) && !dma_fence_is_signaled(fence)) { if (!replacement) replacement = dma_fence_get_stub(); - dma_resv_replace_fences(ttm_bo->base.resv, + dma_resv_replace_fences(&ttm_bo->base._resv, fence->context, replacement, DMA_RESV_USAGE_BOOKKEEP); @@ -1577,7 +1570,7 @@ static void xe_ttm_bo_release_notify(struct ttm_buffer_object *ttm_bo) } dma_fence_put(replacement); - dma_resv_unlock(ttm_bo->base.resv); + dma_resv_unlock(&ttm_bo->base._resv); } static void xe_ttm_bo_delete_mem_notify(struct ttm_buffer_object *ttm_bo) -- 2.51.1

13 hours, 23 minutes

2
4
0 0

+ mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: consider non-anon swap cache folios in folio_expected_ref_count() has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.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 various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Bijan Tabatabai <bijan311(a)gmail.com> Subject: mm: consider non-anon swap cache folios in folio_expected_ref_count() Date: Tue, 16 Dec 2025 14:07:27 -0600 Currently, folio_expected_ref_count() only adds references for the swap cache if the folio is anonymous. However, according to the comment above the definition of PG_swapcache in enum pageflags, shmem folios can also have PG_swapcache set. This patch makes sure references for the swap cache are added if folio_test_swapcache(folio) is true. This issue was found when trying to hot-unplug memory in a QEMU/KVM virtual machine. When initiating hot-unplug when most of the guest memory is allocated, hot-unplug hangs partway through removal due to migration failures. The following message would be printed several times, and would be printed again about every five seconds: [ 49.641309] migrating pfn b12f25 failed ret:7 [ 49.641310] page: refcount:2 mapcount:0 mapping:0000000033bd8fe2 index:0x7f404d925 pfn:0xb12f25 [ 49.641311] aops:swap_aops [ 49.641313] flags: 0x300000000030508(uptodate|active|owner_priv_1|reclaim|swapbacked|node=0|zone=3) [ 49.641314] raw: 0300000000030508 ffffed312c4bc908 ffffed312c4bc9c8 0000000000000000 [ 49.641315] raw: 00000007f404d925 00000000000c823b 00000002ffffffff 0000000000000000 [ 49.641315] page dumped because: migration failure When debugging this, I found that these migration failures were due to __migrate_folio() returning -EAGAIN for a small set of folios because the expected reference count it calculates via folio_expected_ref_count() is one less than the actual reference count of the folios. Furthermore, all of the affected folios were not anonymous, but had the PG_swapcache flag set, inspiring this patch. After applying this patch, the memory hot-unplug behaves as expected. I tested this on a machine running Ubuntu 24.04 with kernel version 6.8.0-90-generic and 64GB of memory. The guest VM is managed by libvirt and runs Ubuntu 24.04 with kernel version 6.18 (though the head of the mm-unstable branch as a Dec 16, 2025 was also tested and behaves the same) and 48GB of memory. The libvirt XML definition for the VM can be found at [1]. CONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_MOVABLE is set in the guest kernel so the hot-pluggable memory is automatically onlined. Below are the steps to reproduce this behavior: 1) Define and start and virtual machine host$ virsh -c qemu:///system define ./test_vm.xml # test_vm.xml from [1] host$ virsh -c qemu:///system start test_vm 2) Setup swap in the guest guest$ sudo fallocate -l 32G /swapfile guest$ sudo chmod 0600 /swapfile guest$ sudo mkswap /swapfile guest$ sudo swapon /swapfile 3) Use alloc_data [2] to allocate most of the remaining guest memory guest$ ./alloc_data 45 4) In a separate guest terminal, monitor the amount of used memory guest$ watch -n1 free -h 5) When alloc_data has finished allocating, initiate the memory hot-unplug using the provided xml file [3] host$ virsh -c qemu:///system detach-device test_vm ./remove.xml --live After initiating the memory hot-unplug, you should see the amount of available memory in the guest decrease, and the amount of used swap data increase. If everything works as expected, when all of the memory is unplugged, there should be around 8.5-9GB of data in swap. If the unplugging is unsuccessful, the amount of used swap data will settle below that. If that happens, you should be able to see log messages in dmesg similar to the one posted above. Link: https://lkml.kernel.org/r/20251216200727.2360228-1-bijan311@gmail.com Link: https://github.com/BijanT/linux_patch_files/blob/main/test_vm.xml [1] Link: https://github.com/BijanT/linux_patch_files/blob/main/alloc_data.c [2] Link: https://github.com/BijanT/linux_patch_files/blob/main/remove.xml [3] Fixes: 86ebd50224c0 ("mm: add folio_expected_ref_count() for reference count calculation") Signed-off-by: Bijan Tabatabai <bijan311(a)gmail.com> Acked-by: David Hildenbrand (Red Hat) <david(a)kernel.org> Acked-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Shivank Garg <shivankg(a)amd.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Kairui Song <ryncsn(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/include/linux/mm.h~mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count +++ a/include/linux/mm.h @@ -2459,10 +2459,10 @@ static inline int folio_expected_ref_cou if (WARN_ON_ONCE(page_has_type(&folio->page) && !folio_test_hugetlb(folio))) return 0; - if (folio_test_anon(folio)) { - /* One reference per page from the swapcache. */ - ref_count += folio_test_swapcache(folio) << order; - } else { + /* One reference per page from the swapcache. */ + ref_count += folio_test_swapcache(folio) << order; + + if (!folio_test_anon(folio)) { /* One reference per page from the pagecache. */ ref_count += !!folio->mapping << order; /* One reference from PG_private. */ _ Patches currently in -mm which might be from bijan311(a)gmail.com are mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.patch

14 hours, 39 minutes

1
0
0 0

[PATCH 0/2] net: qrtr: Drop the MHI 'auto_queue' feature

by Manivannan Sadhasivam via B4 Relay

Hi, This series intends to fix the race between the MHI stack and the MHI client drivers due to the MHI 'auto_queue' feature. As it turns out often, the best way to fix an issue in a feature is to drop the feature itself and this series does exactly that. There is no real benefit in having the 'auto_queue' feature in the MHI stack, other than saving a few lines of code in the client drivers. Since the QRTR is the only client driver which makes use of this feature, this series reworks the QRTR driver to manage the buffer on its own. Testing ======= Tested on Qcom X1E based Lenovo Thinkpad T14s laptop with WLAN device. Merge Strategy ============== Since this series modifies many subsystem drivers, I'd like to get acks from relevant subsystem maintainers and take the series through MHI tree. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com> --- Manivannan Sadhasivam (2): net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels bus: mhi: host: Drop the auto_queue support drivers/accel/qaic/mhi_controller.c | 44 ------------------- drivers/bus/mhi/host/init.c | 10 ----- drivers/bus/mhi/host/internal.h | 3 -- drivers/bus/mhi/host/main.c | 81 +---------------------------------- drivers/bus/mhi/host/pci_generic.c | 20 +-------- drivers/net/wireless/ath/ath11k/mhi.c | 4 -- drivers/net/wireless/ath/ath12k/mhi.c | 4 -- include/linux/mhi.h | 14 ------ net/qrtr/mhi.c | 67 ++++++++++++++++++++++++----- 9 files changed, 60 insertions(+), 187 deletions(-) --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251217-qrtr-fix-c058251d8d1a Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)oss.qualcomm.com>

14 hours, 41 minutes

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror