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

[PATCH v4 2/9] crypto: virtio: Remove duplicated virtqueue_kick in virtio_crypto_skcipher_crypt_req

by Bibo Mao

With function virtio_crypto_skcipher_crypt_req(), there is already virtqueue_kick() call with spinlock held in function __virtio_crypto_skcipher_do_req(). Remove duplicated virtqueue_kick() function call here. Fixes: d79b5d0bbf2e ("crypto: virtio - support crypto engine framework") Cc: stable(a)vger.kernel.org Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- drivers/crypto/virtio/virtio_crypto_skcipher_algs.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c b/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c index 1b3fb21a2a7d..11053d1786d4 100644 --- a/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c +++ b/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c @@ -541,8 +541,6 @@ int virtio_crypto_skcipher_crypt_req( if (ret < 0) return ret; - virtqueue_kick(data_vq->vq); - return 0; } -- 2.39.3

2 days, 13 hours

2
1
0 0

[PATCH v4 1/9] crypto: virtio: Add spinlock protection with virtqueue notification

by Bibo Mao

When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well. Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Cc: stable(a)vger.kernel.org Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> Acked-by: Jason Wang <jasowang(a)redhat.com> --- drivers/crypto/virtio/virtio_crypto_core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/virtio/virtio_crypto_core.c b/drivers/crypto/virtio/virtio_crypto_core.c index 3d241446099c..ccc6b5c1b24b 100644 --- a/drivers/crypto/virtio/virtio_crypto_core.c +++ b/drivers/crypto/virtio/virtio_crypto_core.c @@ -75,15 +75,20 @@ static void virtcrypto_done_task(unsigned long data) struct data_queue *data_vq = (struct data_queue *)data; struct virtqueue *vq = data_vq->vq; struct virtio_crypto_request *vc_req; + unsigned long flags; unsigned int len; + spin_lock_irqsave(&data_vq->lock, flags); do { virtqueue_disable_cb(vq); while ((vc_req = virtqueue_get_buf(vq, &len)) != NULL) { + spin_unlock_irqrestore(&data_vq->lock, flags); if (vc_req->alg_cb) vc_req->alg_cb(vc_req, len); + spin_lock_irqsave(&data_vq->lock, flags); } } while (!virtqueue_enable_cb(vq)); + spin_unlock_irqrestore(&data_vq->lock, flags); } static void virtcrypto_dataq_callback(struct virtqueue *vq) -- 2.39.3

2 days, 13 hours

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. 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

2 days, 14 hours

1
0
0 0

[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

2 days, 14 hours

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

2 days, 14 hours

2
1
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); >

2 days, 18 hours

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

2 days, 18 hours

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

2 days, 18 hours

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

2 days, 19 hours

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

2 days, 20 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror