On Tue, Nov 10, 2020 at 8:51 AM Yi Zhang <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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_hj2zepmysf...@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 -- [email protected] To unsubscribe send an email to [email protected]
