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

[Jason Gunthorpe <jgg@nvidia.com>]

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