regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Yi Zhang]

Hello

I found this regression during devdax fio test on 5.10.0-rc3, could anyone help check it, thanks.

[  303.441089] memmap_init_zone_device initialised 2063872 pages in 34ms
[  303.501085] memmap_init_zone_device initialised 2063872 pages in 34ms
[  303.556891] memmap_init_zone_device initialised 2063872 pages in 24ms
[  303.612790] memmap_init_zone_device initialised 2063872 pages in 24ms
[  326.779920] perf: interrupt took too long (2714 > 2500), lowering kernel.perf_event_max_sample_rate to 73000
[  334.857133] perf: interrupt took too long (3737 > 3392), lowering kernel.perf_event_max_sample_rate to 53000
[  366.202597] memmap_init_zone_device initialised 1835008 pages in 21ms
[  366.255031] memmap_init_zone_device initialised 1835008 pages in 22ms
[  366.317048] memmap_init_zone_device initialised 1835008 pages in 31ms
[  366.377970] memmap_init_zone_device initialised 1835008 pages in 32ms
[  368.785285] BUG: Bad page state in process kworker/41:0  pfn:891066
[  368.818471] page:00000000581ab220 refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x891066
[  368.865117] flags: 0x57ffffc0000000()
[  368.882138] raw: 0057ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[  368.917429] raw: 0000000000000000 0000000000000000 00000000fffffbff 0000000000000000
[  368.952788] page dumped because: nonzero mapcount
[  368.974190] Modules linked in: rfkill sunrpc vfat fat dm_multipath intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp mgag200 ipmi_ssif i2c_algo_bit kvm_intel drm_kms_helper syscopyarea acpi_ipmi sysfillrect kvm sysimgblt ipmi_si fb_sys_fops iTCO_wdt iTCO_vendor_support ipmi_devintf drm irqbypass crct10dif_pclmul ipmi_msghandler crc32_pclmul i2c_i801 ghash_clmulni_intel dax_pmem_compat rapl device_dax i2c_smbus intel_cstate ioatdma intel_uncore joydev hpilo dax_pmem_core pcspkr acpi_tad hpwdt lpc_ich dca acpi_power_meter ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci nfit bnx2x libahci libata tg3 libnvdimm hpsa mdio libcrc32c scsi_transport_sas wmi crc32c_intel dm_mirror dm_region_hash dm_log dm_mod
[  369.281195] CPU: 41 PID: 3258 Comm: kworker/41:0 Tainted: G S                5.10.0-rc3 #1
[  369.321037] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
[  369.363640] Workqueue: mm_percpu_wq vmstat_update
[  369.385044] Call Trace:
[  369.388275] perf: interrupt took too long (5477 > 4671), lowering kernel.perf_event_max_sample_rate to 36000
[  369.396225]  dump_stack+0x57/0x6a
[  369.411391]  bad_page.cold.114+0x9b/0xa0
[  369.429316]  free_pcppages_bulk+0x538/0x760
[  369.448465]  drain_zone_pages+0x1f/0x30
[  369.466027]  refresh_cpu_vm_stats+0x1ea/0x2b0
[  369.485972]  vmstat_update+0xf/0x50
[  369.502064]  process_one_work+0x1a4/0x340
[  369.520412]  ? process_one_work+0x340/0x340
[  369.539510]  worker_thread+0x30/0x370
[  369.555744]  ? process_one_work+0x340/0x340
[  369.574765]  kthread+0x116/0x130
[  369.589612]  ? kthread_park+0x80/0x80
[  369.606231]  ret_from_fork+0x22/0x30
[  369.622910] Disabling lock debugging due to kernel taint
[  393.619285] perf: interrupt took too long (6874 > 6846), lowering kernel.perf_event_max_sample_rate to 29000
[  397.904036] BUG: Bad page state in process kworker/57:1  pfn:189525
[  397.936971] page:00000000be782875 refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x189525
[  397.984722] flags: 0x17ffffc0000000()
[  398.002324] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[  398.039032] raw: 0000000000000000 0000000000000000 00000000fffffbff 0000000000000000
[  398.075804] page dumped because: nonzero mapcount
[  398.098130] Modules linked in: rfkill sunrpc vfat fat dm_multipath intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp mgag200 ipmi_ssif i2c_algo_bit kvm_intel drm_kms_helper syscopyarea acpi_ipmi sysfillrect kvm sysimgblt ipmi_si fb_sys_fops iTCO_wdt iTCO_vendor_support ipmi_devintf drm irqbypass crct10dif_pclmul ipmi_msghandler crc32_pclmul i2c_i801 ghash_clmulni_intel dax_pmem_compat rapl device_dax i2c_smbus intel_cstate ioatdma intel_uncore joydev hpilo dax_pmem_core pcspkr acpi_tad hpwdt lpc_ich dca acpi_power_meter ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci nfit bnx2x libahci libata tg3 libnvdimm hpsa mdio libcrc32c scsi_transport_sas wmi crc32c_intel dm_mirror dm_region_hash dm_log dm_mod
[  398.413042] CPU: 57 PID: 587 Comm: kworker/57:1 Tainted: G S  B             5.10.0-rc3 #1
[  398.455914] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
[  398.496657] Workqueue: mm_percpu_wq vmstat_update
[  398.518938] Call Trace:
[  398.530673]  dump_stack+0x57/0x6a
[  398.546463]  bad_page.cold.114+0x9b/0xa0
[  398.564977]  free_pcppages_bulk+0x538/0x760
[  398.584697]  drain_zone_pages+0x1f/0x30
[  398.602907]  refresh_cpu_vm_stats+0x1ea/0x2b0
[  398.623681]  vmstat_update+0xf/0x50
[  398.640415]  process_one_work+0x1a4/0x340
[  398.659517]  ? process_one_work+0x340/0x340
[  398.678659]  worker_thread+0x30/0x370
[  398.695506]  ? process_one_work+0x340/0x340
[  398.715204]  kthread+0x116/0x130
[  398.730572]  ? kthread_park+0x80/0x80
[  398.747761]  ret_from_fork+0x22/0x30




Best Regards,
  Yi Zhang

_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Dan Williams]

On Sun, Nov 8, 2020 at 6:38 PM Yi Zhang <yi.zhang@redhat.com> wrote:
>
> Hello
>
> I found this regression during devdax fio test on 5.10.0-rc3, could anyone help check it, thanks.

Have you been able to bisect it?
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Yi Zhang]

On 11/9/20 11:00 AM, Dan Williams wrote:
> On Sun, Nov 8, 2020 at 6:38 PM Yi Zhang <yi.zhang@redhat.com> wrote:
>> Hello
>>
>> I found this regression during devdax fio test on 5.10.0-rc3, could anyone help check it, thanks.
> Have you been able to bisect it?
>
Yeah, the bisect is WIP, will update it later. :)
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Yi Zhang]

Hi Dan

By bisecting, this issue was introduced with bellow patch

commit f8f6ae5d077a9bdaf5cbf2ac960a5d1a04b47482
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Sun Nov 1 17:08:00 2020 -0800

     mm: always have io_remap_pfn_range() set pgprot_decrypted()

     The purpose of io_remap_pfn_range() is to map IO memory, such as a
     memory mapped IO exposed through a PCI BAR.  IO devices do not
     understand encryption, so this memory must always be decrypted.
     Automatically call pgprot_decrypted() as part of the generic
     implementation.

     This fixes a bug where enabling AMD SME causes subsystems, such as 
RDMA,
     using io_remap_pfn_range() to expose BAR pages to user space to fail.
     The CPU will encrypt access to those BAR pages instead of passing
     unencrypted IO directly to the device.

     Places not mapping IO should use remap_pfn_range().


On 11/9/20 10:38 AM, Yi Zhang wrote:
> Hello
>
> I found this regression during devdax fio test on 5.10.0-rc3, could anyone help check it, thanks.
>
> [  303.441089] memmap_init_zone_device initialised 2063872 pages in 34ms
> [  303.501085] memmap_init_zone_device initialised 2063872 pages in 34ms
> [  303.556891] memmap_init_zone_device initialised 2063872 pages in 24ms
> [  303.612790] memmap_init_zone_device initialised 2063872 pages in 24ms
> [  326.779920] perf: interrupt took too long (2714 > 2500), lowering kernel.perf_event_max_sample_rate to 73000
> [  334.857133] perf: interrupt took too long (3737 > 3392), lowering kernel.perf_event_max_sample_rate to 53000
> [  366.202597] memmap_init_zone_device initialised 1835008 pages in 21ms
> [  366.255031] memmap_init_zone_device initialised 1835008 pages in 22ms
> [  366.317048] memmap_init_zone_device initialised 1835008 pages in 31ms
> [  366.377970] memmap_init_zone_device initialised 1835008 pages in 32ms
> [  368.785285] BUG: Bad page state in process kworker/41:0  pfn:891066
> [  368.818471] page:00000000581ab220 refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x891066
> [  368.865117] flags: 0x57ffffc0000000()
> [  368.882138] raw: 0057ffffc0000000 dead000000000100 dead000000000122 0000000000000000
> [  368.917429] raw: 0000000000000000 0000000000000000 00000000fffffbff 0000000000000000
> [  368.952788] page dumped because: nonzero mapcount
> [  368.974190] Modules linked in: rfkill sunrpc vfat fat dm_multipath intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp mgag200 ipmi_ssif i2c_algo_bit kvm_intel drm_kms_helper syscopyarea acpi_ipmi sysfillrect kvm sysimgblt ipmi_si fb_sys_fops iTCO_wdt iTCO_vendor_support ipmi_devintf drm irqbypass crct10dif_pclmul ipmi_msghandler crc32_pclmul i2c_i801 ghash_clmulni_intel dax_pmem_compat rapl device_dax i2c_smbus intel_cstate ioatdma intel_uncore joydev hpilo dax_pmem_core pcspkr acpi_tad hpwdt lpc_ich dca acpi_power_meter ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci nfit bnx2x libahci libata tg3 libnvdimm hpsa mdio libcrc32c scsi_transport_sas wmi crc32c_intel dm_mirror dm_region_hash dm_log dm_mod
> [  369.281195] CPU: 41 PID: 3258 Comm: kworker/41:0 Tainted: G S                5.10.0-rc3 #1
> [  369.321037] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
> [  369.363640] Workqueue: mm_percpu_wq vmstat_update
> [  369.385044] Call Trace:
> [  369.388275] perf: interrupt took too long (5477 > 4671), lowering kernel.perf_event_max_sample_rate to 36000
> [  369.396225]  dump_stack+0x57/0x6a
> [  369.411391]  bad_page.cold.114+0x9b/0xa0
> [  369.429316]  free_pcppages_bulk+0x538/0x760
> [  369.448465]  drain_zone_pages+0x1f/0x30
> [  369.466027]  refresh_cpu_vm_stats+0x1ea/0x2b0
> [  369.485972]  vmstat_update+0xf/0x50
> [  369.502064]  process_one_work+0x1a4/0x340
> [  369.520412]  ? process_one_work+0x340/0x340
> [  369.539510]  worker_thread+0x30/0x370
> [  369.555744]  ? process_one_work+0x340/0x340
> [  369.574765]  kthread+0x116/0x130
> [  369.589612]  ? kthread_park+0x80/0x80
> [  369.606231]  ret_from_fork+0x22/0x30
> [  369.622910] Disabling lock debugging due to kernel taint
> [  393.619285] perf: interrupt took too long (6874 > 6846), lowering kernel.perf_event_max_sample_rate to 29000
> [  397.904036] BUG: Bad page state in process kworker/57:1  pfn:189525
> [  397.936971] page:00000000be782875 refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x189525
> [  397.984722] flags: 0x17ffffc0000000()
> [  398.002324] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
> [  398.039032] raw: 0000000000000000 0000000000000000 00000000fffffbff 0000000000000000
> [  398.075804] page dumped because: nonzero mapcount
> [  398.098130] Modules linked in: rfkill sunrpc vfat fat dm_multipath intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp mgag200 ipmi_ssif i2c_algo_bit kvm_intel drm_kms_helper syscopyarea acpi_ipmi sysfillrect kvm sysimgblt ipmi_si fb_sys_fops iTCO_wdt iTCO_vendor_support ipmi_devintf drm irqbypass crct10dif_pclmul ipmi_msghandler crc32_pclmul i2c_i801 ghash_clmulni_intel dax_pmem_compat rapl device_dax i2c_smbus intel_cstate ioatdma intel_uncore joydev hpilo dax_pmem_core pcspkr acpi_tad hpwdt lpc_ich dca acpi_power_meter ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci nfit bnx2x libahci libata tg3 libnvdimm hpsa mdio libcrc32c scsi_transport_sas wmi crc32c_intel dm_mirror dm_region_hash dm_log dm_mod
> [  398.413042] CPU: 57 PID: 587 Comm: kworker/57:1 Tainted: G S  B             5.10.0-rc3 #1
> [  398.455914] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
> [  398.496657] Workqueue: mm_percpu_wq vmstat_update
> [  398.518938] Call Trace:
> [  398.530673]  dump_stack+0x57/0x6a
> [  398.546463]  bad_page.cold.114+0x9b/0xa0
> [  398.564977]  free_pcppages_bulk+0x538/0x760
> [  398.584697]  drain_zone_pages+0x1f/0x30
> [  398.602907]  refresh_cpu_vm_stats+0x1ea/0x2b0
> [  398.623681]  vmstat_update+0xf/0x50
> [  398.640415]  process_one_work+0x1a4/0x340
> [  398.659517]  ? process_one_work+0x340/0x340
> [  398.678659]  worker_thread+0x30/0x370
> [  398.695506]  ? process_one_work+0x340/0x340
> [  398.715204]  kthread+0x116/0x130
> [  398.730572]  ? kthread_park+0x80/0x80
> [  398.747761]  ret_from_fork+0x22/0x30
>
>
>
>
> Best Regards,
>    Yi Zhang
>
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
>
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Dan Williams]

On Mon, Nov 9, 2020 at 6:12 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> Wow, this is surprising
>
> This has been widely backported already, Dan please check??
>
> I thought pgprot_decrypted was a NOP on most x86 platforms -
> sme_me_mask == 0:
>
> #define __sme_set(x)            ((x) | sme_me_mask)
> #define __sme_clr(x)            ((x) & ~sme_me_mask)
>
> ??
>
> Confused how this can be causing DAX issues

Does that correctly preserve the "soft" pte bits? Especially
PTE_DEVMAP that DAX uses?

I'll check...
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Jason Gunthorpe]

On Mon, Nov 09, 2020 at 01:54:42PM -0400, Jason Gunthorpe wrote:
> On Mon, Nov 09, 2020 at 09:26:19AM -0800, Dan Williams wrote:
> > On Mon, Nov 9, 2020 at 6:12 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > >
> > > Wow, this is surprising
> > >
> > > This has been widely backported already, Dan please check??
> > >
> > > I thought pgprot_decrypted was a NOP on most x86 platforms -
> > > sme_me_mask == 0:
> > >
> > > #define __sme_set(x)            ((x) | sme_me_mask)
> > > #define __sme_clr(x)            ((x) & ~sme_me_mask)
> > >
> > > ??
> > >
> > > Confused how this can be causing DAX issues
> > 
> > Does that correctly preserve the "soft" pte bits? Especially
> > PTE_DEVMAP that DAX uses?
> > 
> > I'll check...
> 
>  extern u64 sme_me_mask;
>  #define __pgprot(x)		((pgprot_t) { (x) } )
>  #define pgprot_val(x)		((x).pgprot)
>  #define __sme_clr(x)            ((x) & ~sme_me_mask)
>  #define pgprot_decrypted(prot)   __pgprot(__sme_clr(pgprot_val(prot)))
> 
>  static inline int io_remap_pfn_range(struct vm_area_struct *vma,
>                                      unsigned long addr, unsigned long pfn,
>                                      unsigned long size, pgprot_t prot)
>  {
>        return remap_pfn_range(vma, addr, pfn, size, pgprot_decrypted(prot));
>  }
> 
> Not seeing how that could change the pgprot in any harmful way?
> 
> Yi, are you using a platform where sme_me_mask != 0 ? 
> 
> That code looks clearly like it would only trigger on AMD SME systems,
> is that what you are using?

Can't be, the system is too old:

 [  398.455914] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016

I'm at a total loss how this change could even do anything on a
non-AMD system, let alone how this intersects in any way with DEVDAX,
which I could not find being used with io_remap_pfn_range()

How confident are you in the bisection?

Jason
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Yi Zhang]

On 11/10/20 8:36 AM, Jason Gunthorpe wrote:
> On Mon, Nov 09, 2020 at 01:54:42PM -0400, Jason Gunthorpe wrote:
>> On Mon, Nov 09, 2020 at 09:26:19AM -0800, Dan Williams wrote:
>>> On Mon, Nov 9, 2020 at 6:12 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>>> Wow, this is surprising
>>>>
>>>> This has been widely backported already, Dan please check??
>>>>
>>>> I thought pgprot_decrypted was a NOP on most x86 platforms -
>>>> sme_me_mask == 0:
>>>>
>>>> #define __sme_set(x)            ((x) | sme_me_mask)
>>>> #define __sme_clr(x)            ((x) & ~sme_me_mask)
>>>>
>>>> ??
>>>>
>>>> Confused how this can be causing DAX issues
>>> Does that correctly preserve the "soft" pte bits? Especially
>>> PTE_DEVMAP that DAX uses?
>>>
>>> I'll check...
>>   extern u64 sme_me_mask;
>>   #define __pgprot(x)		((pgprot_t) { (x) } )
>>   #define pgprot_val(x)		((x).pgprot)
>>   #define __sme_clr(x)            ((x) & ~sme_me_mask)
>>   #define pgprot_decrypted(prot)   __pgprot(__sme_clr(pgprot_val(prot)))
>>
>>   static inline int io_remap_pfn_range(struct vm_area_struct *vma,
>>                                       unsigned long addr, unsigned long pfn,
>>                                       unsigned long size, pgprot_t prot)
>>   {
>>         return remap_pfn_range(vma, addr, pfn, size, pgprot_decrypted(prot));
>>   }
>>
>> Not seeing how that could change the pgprot in any harmful way?
>>
>> Yi, are you using a platform where sme_me_mask != 0 ?
>>
>> That code looks clearly like it would only trigger on AMD SME systems,
>> is that what you are using?
> Can't be, the system is too old:
>
>   [  398.455914] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
>
> I'm at a total loss how this change could even do anything on a
> non-AMD system, let alone how this intersects in any way with DEVDAX,
> which I could not find being used with io_remap_pfn_range()

I will double confirm it.

> How confident are you in the bisection?
>
> Jason
>
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Yi Zhang]

On 11/10/20 3:36 PM, Yi Zhang wrote:
>
>
> On 11/10/20 8:36 AM, Jason Gunthorpe wrote:
>> On Mon, Nov 09, 2020 at 01:54:42PM -0400, Jason Gunthorpe wrote:
>>> On Mon, Nov 09, 2020 at 09:26:19AM -0800, Dan Williams wrote:
>>>> On Mon, Nov 9, 2020 at 6:12 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>>>> Wow, this is surprising
>>>>>
>>>>> This has been widely backported already, Dan please check??
>>>>>
>>>>> I thought pgprot_decrypted was a NOP on most x86 platforms -
>>>>> sme_me_mask == 0:
>>>>>
>>>>> #define __sme_set(x)            ((x) | sme_me_mask)
>>>>> #define __sme_clr(x)            ((x) & ~sme_me_mask)
>>>>>
>>>>> ??
>>>>>
>>>>> Confused how this can be causing DAX issues
>>>> Does that correctly preserve the "soft" pte bits? Especially
>>>> PTE_DEVMAP that DAX uses?
>>>>
>>>> I'll check...
>>>   extern u64 sme_me_mask;
>>>   #define __pgprot(x)        ((pgprot_t) { (x) } )
>>>   #define pgprot_val(x)        ((x).pgprot)
>>>   #define __sme_clr(x)            ((x) & ~sme_me_mask)
>>>   #define pgprot_decrypted(prot) __pgprot(__sme_clr(pgprot_val(prot)))
>>>
>>>   static inline int io_remap_pfn_range(struct vm_area_struct *vma,
>>>                                       unsigned long addr, unsigned 
>>> long pfn,
>>>                                       unsigned long size, pgprot_t 
>>> prot)
>>>   {
>>>         return remap_pfn_range(vma, addr, pfn, size, 
>>> pgprot_decrypted(prot));
>>>   }
>>>
>>> Not seeing how that could change the pgprot in any harmful way?
>>>
>>> Yi, are you using a platform where sme_me_mask != 0 ?
>>>
>>> That code looks clearly like it would only trigger on AMD SME systems,
>>> is that what you are using?
>> Can't be, the system is too old:
>>
>>   [  398.455914] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 
>> Gen9, BIOS P89 10/05/2016
>>
>> I'm at a total loss how this change could even do anything on a
>> non-AMD system, let alone how this intersects in any way with DEVDAX,
>> which I could not find being used with io_remap_pfn_range()
>
> I will double confirm it.
>
Hi Dan/Jason

It turns out that it was introduced by bellow patch[1] which fixed the 
"static key devmap_managed_key" issue, but introduced [2]
Finally I found it was not 100% reproduced, and sorry for my mistake.

[1]
commit 46b1ee38b2ba1a9524c8e886ad078bd3ca40de2a (HEAD)
Author: Ralph Campbell <rcampbell@nvidia.com>
Date:   Sun Nov 1 17:07:23 2020 -0800

     mm/mremap_pages: fix static key devmap_managed_key updates

[2]
[ 1129.792673] memmap_init_zone_device initialised 2063872 pages in 34ms
[ 1129.865469] memmap_init_zone_device initialised 2063872 pages in 34ms
[ 1129.924080] memmap_init_zone_device initialised 2063872 pages in 24ms
[ 1129.987160] memmap_init_zone_device initialised 2063872 pages in 25ms
[ 1170.785114] BUG: Bad page state in process kworker/67:2 pfn:189e3e
[ 1170.815859] page:000000002f5fe047 refcount:0 mapcount:-1024 
mapping:0000000000000000 index:0x0 pfn:0x189e3e
[ 1170.864772] flags: 0x17ffffc0000000()
[ 1170.883291] raw: 0017ffffc0000000 dead000000000100 dead000000000122 
0000000000000000
[ 1170.920537] raw: 0000000000000000 0000000000000000 00000000fffffbff 
0000000000000000
[ 1170.957627] page dumped because: nonzero mapcount
[ 1170.980101] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 
dns_resolver nfs lockd grace nfs_ssc fscache rfkill sunrpc vfat fat 
dm_multipath intel_rapl_msr intel_rapl_common sb_edac 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm 
irqbypass mgag200 crct10dif_pclmul iTCO_wdt i2c_algo_bit crc32_pclmul 
iTCO_vendor_support drm_kms_helper syscopyarea acpi_ipmi 
ghash_clmulni_intel sysfillrect ipmi_si rapl sysimgblt fb_sys_fops 
i2c_i801 ipmi_devintf drm ipmi_msghandler intel_cstate intel_uncore 
dax_pmem_compat device_dax ioatdma i2c_smbus acpi_tad joydev 
dax_pmem_core pcspkr hpwdt lpc_ich acpi_power_meter hpilo dca ip_tables 
xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci bnx2x libahci nfit 
libata tg3 libnvdimm hpsa mdio scsi_transport_sas libcrc32c wmi 
crc32c_intel dm_mirror dm_region_hash dm_log dm_mod
[ 1171.332281] CPU: 67 PID: 2700 Comm: kworker/67:2 Tainted: G 
S                5.10.0-rc2.46b1ee38b2ba+ #4
[ 1171.378334] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 
Gen9, BIOS P89 10/05/2016
[ 1171.419774] Workqueue: mm_percpu_wq vmstat_update
[ 1171.442726] Call Trace:
[ 1171.454481]  dump_stack+0x57/0x6a
[ 1171.470597]  bad_page.cold.114+0x9b/0xa0
[ 1171.489841]  free_pcppages_bulk+0x538/0x760
[ 1171.509124]  drain_zone_pages+0x1f/0x30
[ 1171.527649]  refresh_cpu_vm_stats+0x1ea/0x2b0
[ 1171.548935]  vmstat_update+0xf/0x50
[ 1171.565961]  process_one_work+0x1a4/0x340
[ 1171.585142]  ? process_one_work+0x340/0x340
[ 1171.605147]  worker_thread+0x30/0x370
[ 1171.622603]  ? process_one_work+0x340/0x340
[ 1171.642355]  kthread+0x116/0x130
[ 1171.657519]  ? kthread_park+0x80/0x80
[ 1171.674713]  ret_from_fork+0x22/0x30
[ 1171.691291] Disabling lock debugging due to kernel taint

>> How confident are you in the bisection?
>>
>> Jason
>>
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
>
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Yi Zhang]

Add Ralph

>>
> Hi Dan/Jason
>
> It turns out that it was introduced by bellow patch[1] which fixed the 
> "static key devmap_managed_key" issue, but introduced [2]
> Finally I found it was not 100% reproduced, and sorry for my mistake.
>
> [1]
> commit 46b1ee38b2ba1a9524c8e886ad078bd3ca40de2a (HEAD)
> Author: Ralph Campbell <rcampbell@nvidia.com>
> Date:   Sun Nov 1 17:07:23 2020 -0800
>
>     mm/mremap_pages: fix static key devmap_managed_key updates
>
> [2]
> [ 1129.792673] memmap_init_zone_device initialised 2063872 pages in 34ms
> [ 1129.865469] memmap_init_zone_device initialised 2063872 pages in 34ms
> [ 1129.924080] memmap_init_zone_device initialised 2063872 pages in 24ms
> [ 1129.987160] memmap_init_zone_device initialised 2063872 pages in 25ms
> [ 1170.785114] BUG: Bad page state in process kworker/67:2 pfn:189e3e
> [ 1170.815859] page:000000002f5fe047 refcount:0 mapcount:-1024 
> mapping:0000000000000000 index:0x0 pfn:0x189e3e
> [ 1170.864772] flags: 0x17ffffc0000000()
> [ 1170.883291] raw: 0017ffffc0000000 dead000000000100 dead000000000122 
> 0000000000000000
> [ 1170.920537] raw: 0000000000000000 0000000000000000 00000000fffffbff 
> 0000000000000000
> [ 1170.957627] page dumped because: nonzero mapcount
> [ 1170.980101] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 
> dns_resolver nfs lockd grace nfs_ssc fscache rfkill sunrpc vfat fat 
> dm_multipath intel_rapl_msr intel_rapl_common sb_edac 
> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm 
> irqbypass mgag200 crct10dif_pclmul iTCO_wdt i2c_algo_bit crc32_pclmul 
> iTCO_vendor_support drm_kms_helper syscopyarea acpi_ipmi 
> ghash_clmulni_intel sysfillrect ipmi_si rapl sysimgblt fb_sys_fops 
> i2c_i801 ipmi_devintf drm ipmi_msghandler intel_cstate intel_uncore 
> dax_pmem_compat device_dax ioatdma i2c_smbus acpi_tad joydev 
> dax_pmem_core pcspkr hpwdt lpc_ich acpi_power_meter hpilo dca 
> ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci bnx2x 
> libahci nfit libata tg3 libnvdimm hpsa mdio scsi_transport_sas 
> libcrc32c wmi crc32c_intel dm_mirror dm_region_hash dm_log dm_mod
> [ 1171.332281] CPU: 67 PID: 2700 Comm: kworker/67:2 Tainted: G 
> S                5.10.0-rc2.46b1ee38b2ba+ #4
> [ 1171.378334] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 
> Gen9, BIOS P89 10/05/2016
> [ 1171.419774] Workqueue: mm_percpu_wq vmstat_update
> [ 1171.442726] Call Trace:
> [ 1171.454481]  dump_stack+0x57/0x6a
> [ 1171.470597]  bad_page.cold.114+0x9b/0xa0
> [ 1171.489841]  free_pcppages_bulk+0x538/0x760
> [ 1171.509124]  drain_zone_pages+0x1f/0x30
> [ 1171.527649]  refresh_cpu_vm_stats+0x1ea/0x2b0
> [ 1171.548935]  vmstat_update+0xf/0x50
> [ 1171.565961]  process_one_work+0x1a4/0x340
> [ 1171.585142]  ? process_one_work+0x340/0x340
> [ 1171.605147]  worker_thread+0x30/0x370
> [ 1171.622603]  ? process_one_work+0x340/0x340
> [ 1171.642355]  kthread+0x116/0x130
> [ 1171.657519]  ? kthread_park+0x80/0x80
> [ 1171.674713]  ret_from_fork+0x22/0x30
> [ 1171.691291] Disabling lock debugging due to kernel taint
>
>>> How confident are you in the bisection?
>>>
>>> Jason
>>>
>> _______________________________________________
>> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
>> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
>>
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Yi Zhang]

ping
This issue still can be reproduced on 5.10.0-rc4

[ 1914.356562] BUG: Bad page state in process kworker/58:0  pfn:1fadf5
[ 1914.390159] page:00000000fee4d2a1 refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x1fadf5
[ 1914.436292] flags: 0x17ffffc0000000()
[ 1914.452792] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[ 1914.488322] raw: 0000000000000000 0000000000000000 00000000fffffbff 0000000000000000
[ 1914.523625] page dumped because: nonzero mapcount
[ 1914.544972] Modules linked in: dm_log_writes loop ext4 mbcache jbd2 rfkill sunrpc vfat fat dm_multipath intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass mgag200 crct10dif_pclmul i2c_algo_bit drm_kms_helper syscopyarea crc32_pclmul ghash_clmulni_intel iTCO_wdt sysfillrect sysimgblt rapl fb_sys_fops intel_cstate iTCO_vendor_support drm dax_pmem_compat ipmi_ssif device_dax intel_uncore pcspkr dax_pmem_core i2c_i801 lpc_ich acpi_ipmi ipmi_si joydev ipmi_devintf acpi_tad ipmi_msghandler hpilo hpwdt i2c_smbus ioatdma acpi_power_meter dca ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci bnx2x nfit libahci libata tg3 libnvdimm hpsa mdio libcrc32c scsi_transport_sas crc32c_intel wmi dm_mirror dm_region_hash dm_log dm_mod
[ 1914.862181] CPU: 58 PID: 14617 Comm: kworker/58:0 Tainted: G S  B             5.10.0-rc4 #1
[ 1914.903469] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
[ 1914.945189] Workqueue: mm_percpu_wq vmstat_update
[ 1914.966350] Call Trace:
[ 1914.977331]  dump_stack+0x57/0x6a
[ 1914.992193]  bad_page.cold.114+0x9b/0xa0
[ 1915.009908]  free_pcppages_bulk+0x538/0x760
[ 1915.029226]  drain_zone_pages+0x1f/0x30
[ 1915.046526]  refresh_cpu_vm_stats+0x1ea/0x2b0
[ 1915.066113]  vmstat_update+0xf/0x50
[ 1915.081784]  process_one_work+0x1a4/0x340
[ 1915.099858]  ? process_one_work+0x340/0x340
[ 1915.118741]  worker_thread+0x30/0x370
[ 1915.135268]  ? process_one_work+0x340/0x340
[ 1915.154211]  kthread+0x116/0x130
[ 1915.168771]  ? kthread_park+0x80/0x80
[ 1915.185635]  ret_from_fork+0x22/0x30
[ 1972.063440] restraintd[2377]: *** Current Time: Mon Nov 16 00:56:57 2020  Localwatchdog at: Mon Nov 16 02:55:57 2020
[ 1976.501706] BUG: Bad page state in process kworker/4:0  pfn:a24692
[ 1976.532586] page:00000000f000e4ba refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0xa24692
[ 1976.581869] flags: 0x57ffffc0000000()
[ 1976.599064] raw: 0057ffffc0000000 dead000000000100 dead000000000122 0000000000000000
[ 1976.635786] raw: 0000000000000000 0000000000000000 00000000fffffbff 0000000000000000
[ 1976.671862] page dumped because: nonzero mapcount
[ 1976.694287] Modules linked in: dm_log_writes loop ext4 mbcache jbd2 rfkill sunrpc vfat fat dm_multipath intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass mgag200 crct10dif_pclmul i2c_algo_bit drm_kms_helper syscopyarea crc32_pclmul ghash_clmulni_intel iTCO_wdt sysfillrect sysimgblt rapl fb_sys_fops intel_cstate iTCO_vendor_support drm dax_pmem_compat ipmi_ssif device_dax intel_uncore pcspkr dax_pmem_core i2c_i801 lpc_ich acpi_ipmi ipmi_si joydev ipmi_devintf acpi_tad ipmi_msghandler hpilo hpwdt i2c_smbus ioatdma acpi_power_meter dca ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci bnx2x nfit libahci libata tg3 libnvdimm hpsa mdio libcrc32c scsi_transport_sas crc32c_intel wmi dm_mirror dm_region_hash dm_log dm_mod
[ 1977.024006] CPU: 4 PID: 23471 Comm: kworker/4:0 Tainted: G S  B             5.10.0-rc4 #1
[ 1977.067069] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
[ 1977.106156] Workqueue: mm_percpu_wq vmstat_update
[ 1977.128645] Call Trace:
[ 1977.140263]  dump_stack+0x57/0x6a
[ 1977.155844]  bad_page.cold.114+0x9b/0xa0
[ 1977.174451]  free_pcppages_bulk+0x538/0x760
[ 1977.194417]  drain_zone_pages+0x1f/0x30
[ 1977.212748]  refresh_cpu_vm_stats+0x1ea/0x2b0
[ 1977.233450]  vmstat_update+0xf/0x50
[ 1977.249779]  process_one_work+0x1a4/0x340
[ 1977.268797]  ? process_one_work+0x340/0x340
[ 1977.288564]  worker_thread+0x30/0x370
[ 1977.306138]  ? process_one_work+0x340/0x340
[ 1977.326017]  kthread+0x116/0x130
[ 1977.341274]  ? kthread_park+0x80/0x80
[ 1977.358649]  ret_from_fork+0x22/0x30



On 11/11/20 11:44 AM, Yi Zhang wrote:
> Add Ralph
>
>>>
>> Hi Dan/Jason
>>
>> It turns out that it was introduced by bellow patch[1] which fixed 
>> the "static key devmap_managed_key" issue, but introduced [2]
>> Finally I found it was not 100% reproduced, and sorry for my mistake.
>>
>> [1]
>> commit 46b1ee38b2ba1a9524c8e886ad078bd3ca40de2a (HEAD)
>> Author: Ralph Campbell <rcampbell@nvidia.com>
>> Date:   Sun Nov 1 17:07:23 2020 -0800
>>
>>     mm/mremap_pages: fix static key devmap_managed_key updates
>>
>> [2]
>> [ 1129.792673] memmap_init_zone_device initialised 2063872 pages in 34ms
>> [ 1129.865469] memmap_init_zone_device initialised 2063872 pages in 34ms
>> [ 1129.924080] memmap_init_zone_device initialised 2063872 pages in 24ms
>> [ 1129.987160] memmap_init_zone_device initialised 2063872 pages in 25ms
>> [ 1170.785114] BUG: Bad page state in process kworker/67:2 pfn:189e3e
>> [ 1170.815859] page:000000002f5fe047 refcount:0 mapcount:-1024 
>> mapping:0000000000000000 index:0x0 pfn:0x189e3e
>> [ 1170.864772] flags: 0x17ffffc0000000()
>> [ 1170.883291] raw: 0017ffffc0000000 dead000000000100 
>> dead000000000122 0000000000000000
>> [ 1170.920537] raw: 0000000000000000 0000000000000000 
>> 00000000fffffbff 0000000000000000
>> [ 1170.957627] page dumped because: nonzero mapcount
>> [ 1170.980101] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 
>> dns_resolver nfs lockd grace nfs_ssc fscache rfkill sunrpc vfat fat 
>> dm_multipath intel_rapl_msr intel_rapl_common sb_edac 
>> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif 
>> kvm irqbypass mgag200 crct10dif_pclmul iTCO_wdt i2c_algo_bit 
>> crc32_pclmul iTCO_vendor_support drm_kms_helper syscopyarea acpi_ipmi 
>> ghash_clmulni_intel sysfillrect ipmi_si rapl sysimgblt fb_sys_fops 
>> i2c_i801 ipmi_devintf drm ipmi_msghandler intel_cstate intel_uncore 
>> dax_pmem_compat device_dax ioatdma i2c_smbus acpi_tad joydev 
>> dax_pmem_core pcspkr hpwdt lpc_ich acpi_power_meter hpilo dca 
>> ip_tables xfs sr_mod cdrom sd_mod t10_pi sg nd_pmem nd_btt ahci bnx2x 
>> libahci nfit libata tg3 libnvdimm hpsa mdio scsi_transport_sas 
>> libcrc32c wmi crc32c_intel dm_mirror dm_region_hash dm_log dm_mod
>> [ 1171.332281] CPU: 67 PID: 2700 Comm: kworker/67:2 Tainted: G 
>> S                5.10.0-rc2.46b1ee38b2ba+ #4
>> [ 1171.378334] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 
>> Gen9, BIOS P89 10/05/2016
>> [ 1171.419774] Workqueue: mm_percpu_wq vmstat_update
>> [ 1171.442726] Call Trace:
>> [ 1171.454481]  dump_stack+0x57/0x6a
>> [ 1171.470597]  bad_page.cold.114+0x9b/0xa0
>> [ 1171.489841]  free_pcppages_bulk+0x538/0x760
>> [ 1171.509124]  drain_zone_pages+0x1f/0x30
>> [ 1171.527649]  refresh_cpu_vm_stats+0x1ea/0x2b0
>> [ 1171.548935]  vmstat_update+0xf/0x50
>> [ 1171.565961]  process_one_work+0x1a4/0x340
>> [ 1171.585142]  ? process_one_work+0x340/0x340
>> [ 1171.605147]  worker_thread+0x30/0x370
>> [ 1171.622603]  ? process_one_work+0x340/0x340
>> [ 1171.642355]  kthread+0x116/0x130
>> [ 1171.657519]  ? kthread_park+0x80/0x80
>> [ 1171.674713]  ret_from_fork+0x22/0x30
>> [ 1171.691291] Disabling lock debugging due to kernel taint
>>
>>>> How confident are you in the bisection?
>>>>
>>>> Jason
>>>>
>>> _______________________________________________
>>> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
>>> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
>>>
>> _______________________________________________
>> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
>> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

Re: regression from 5.10.0-rc3: BUG: Bad page state in process kworker/41:0 pfn:891066 during fio on devdax

[Dan Williams]

On Tue, Nov 10, 2020 at 8:51 AM Yi Zhang <yi.zhang@redhat.com> wrote:
>
>
>
> On 11/10/20 3:36 PM, Yi Zhang wrote:
> >
> >
> > On 11/10/20 8:36 AM, Jason Gunthorpe wrote:
> >> On Mon, Nov 09, 2020 at 01:54:42PM -0400, Jason Gunthorpe wrote:
> >>> On Mon, Nov 09, 2020 at 09:26:19AM -0800, Dan Williams wrote:
> >>>> On Mon, Nov 9, 2020 at 6:12 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >>>>> Wow, this is surprising
> >>>>>
> >>>>> This has been widely backported already, Dan please check??
> >>>>>
> >>>>> I thought pgprot_decrypted was a NOP on most x86 platforms -
> >>>>> sme_me_mask == 0:
> >>>>>
> >>>>> #define __sme_set(x)            ((x) | sme_me_mask)
> >>>>> #define __sme_clr(x)            ((x) & ~sme_me_mask)
> >>>>>
> >>>>> ??
> >>>>>
> >>>>> Confused how this can be causing DAX issues
> >>>> Does that correctly preserve the "soft" pte bits? Especially
> >>>> PTE_DEVMAP that DAX uses?
> >>>>
> >>>> I'll check...
> >>>   extern u64 sme_me_mask;
> >>>   #define __pgprot(x)        ((pgprot_t) { (x) } )
> >>>   #define pgprot_val(x)        ((x).pgprot)
> >>>   #define __sme_clr(x)            ((x) & ~sme_me_mask)
> >>>   #define pgprot_decrypted(prot) __pgprot(__sme_clr(pgprot_val(prot)))
> >>>
> >>>   static inline int io_remap_pfn_range(struct vm_area_struct *vma,
> >>>                                       unsigned long addr, unsigned
> >>> long pfn,
> >>>                                       unsigned long size, pgprot_t
> >>> prot)
> >>>   {
> >>>         return remap_pfn_range(vma, addr, pfn, size,
> >>> pgprot_decrypted(prot));
> >>>   }
> >>>
> >>> Not seeing how that could change the pgprot in any harmful way?
> >>>
> >>> Yi, are you using a platform where sme_me_mask != 0 ?
> >>>
> >>> That code looks clearly like it would only trigger on AMD SME systems,
> >>> is that what you are using?
> >> Can't be, the system is too old:
> >>
> >>   [  398.455914] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380
> >> Gen9, BIOS P89 10/05/2016
> >>
> >> I'm at a total loss how this change could even do anything on a
> >> non-AMD system, let alone how this intersects in any way with DEVDAX,
> >> which I could not find being used with io_remap_pfn_range()
> >
> > I will double confirm it.
> >
> Hi Dan/Jason
>
> It turns out that it was introduced by bellow patch[1] which fixed the
> "static key devmap_managed_key" issue, but introduced [2]
> Finally I found it was not 100% reproduced, and sorry for my mistake.
>
> [1]
> commit 46b1ee38b2ba1a9524c8e886ad078bd3ca40de2a (HEAD)
> Author: Ralph Campbell <rcampbell@nvidia.com>
> Date:   Sun Nov 1 17:07:23 2020 -0800
>
>      mm/mremap_pages: fix static key devmap_managed_key updates

Are you confident about this bisect? I am seeing a similar issue here:

https://lore.kernel.org/linux-nvdimm/CAPcyv4isen63tJ7q02rvVuu_Rm6QPdT0Bu-P_HJ2zePMySFNNg@mail.gmail.com

...and my bisect attempts have never landed on this commit.
Unfortunately my bisect attempts also don't land on anything that
looks like the real culprit.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org