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

[David Hildenbrand]

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