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

[David Hildenbrand <david@redhat.com>]

On 20.12.23 23:11, Andrew Morton wrote:
> On Tue, 19 Dec 2023 23:46:50 +0800 kernel test robot <oliver.sang@intel.com> 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@intel.com>
>> | Closes: https://lore.kernel.org/oe-lkp/202312192319.fa8f5709-oliver.sang@intel.com
>>
>>
>> [   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@casper.infradead.org) 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