Re: [linux-next:master] [mm] bbcbf2a3f0: kernel_BUG_at_mm/memory.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20.12.23 23:11, Andrew Morton wrote:
On Tue, 19 Dec 2023 23:46:50 +0800 kernel test robot <oliver.sang@xxxxxxxxx> wrote:



Hello,

kernel test robot noticed "kernel_BUG_at_mm/memory.c" on:

commit: bbcbf2a3f05f74f9d268eab57abbdce6a65a94ad ("mm: convert ksm_might_need_to_copy() to work on folios")

I assume this is a bisection result, so it's quite repeatable?

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

[test failed on linux-next/master aa4db8324c4d0e67aa4670356df4e9fae14b4d37]

in testcase: vm-scalability
version: vm-scalability-x86_64-1.0-0_20220518
with following parameters:

	runtime: 300
	thp_enabled: always
	thp_defrag: always
	nr_task: 32
	nr_ssd: 1
	priority: 1
	test: swap-w-rand
	cpufreq_governor: performance

test-description: The motivation behind this suite is to exercise functions and regions of the mm/ of the Linux kernel which are of interest to us.
test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/


compiler: gcc-12
test machine: 128 threads 2 sockets Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz (Ice Lake) with 128G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
| Closes: https://lore.kernel.org/oe-lkp/202312192319.fa8f5709-oliver.sang@xxxxxxxxx


[   61.404380][ T5947] ------------[ cut here ]------------
[   61.409984][ T5947] kernel BUG at mm/memory.c:3990!
[   61.415085][ T5947] invalid opcode: 0000 [#1] SMP NOPTI

This is

	BUG_ON(folio_test_anon(folio) && PageAnonExclusive(page));

and I don't believe that the error path fix
(https://lkml.kernel.org/r/ZXnPtblC6A1IkyAB@xxxxxxxxxxxxxxxxxxxx) will
address this.

Matthew, have you had a chance to consider?

Isn't the
	
	page = folio_page(folio, 0);

just wrong?

We must not do that if the folio didn't change, otherwise we're
in trouble if we had a large folio in the swapcache.


Maybe something like the following?

diff --git a/mm/memory.c b/mm/memory.c
index d995ead7a3933..3aca5e33c6f81 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3961,7 +3961,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
                        folio = swapcache;
                        goto out_page;
                }
-               page = folio_page(folio, 0);
+               if (folio != swapcache)
+                       page = folio_page(folio, 0);
/*
                 * If we want to map a page that's in the swapcache writable, we





--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux