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

[Yi Zhang <yi.zhang@redhat.com>]

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