[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b8ecc05f-859e-4710-8c4c-a24ac82bff11@redhat.com>
Date: Wed, 20 Dec 2023 23:29:09 +0100
From: David Hildenbrand <david@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
kernel test robot <oliver.sang@...el.com>
Cc: Matthew Wilcox <willy@...radead.org>, oe-lkp@...ts.linux.dev,
lkp@...el.com, Linux Memory Management List <linux-mm@...ck.org>,
linux-kernel@...r.kernel.org
Subject: Re: [linux-next:master] [mm] bbcbf2a3f0: kernel_BUG_at_mm/memory.c
On 20.12.23 23:11, Andrew Morton wrote:
> On Tue, 19 Dec 2023 23:46:50 +0800 kernel test robot <oliver.sang@...el.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@...el.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
Powered by blists - more mailing lists