On Tue, Nov 07, 2017 at 10:31:36AM +0200, Nadav Har'El wrote:
>
> > However, this didn't help initially as the memory wasn't being populated.
> > I altered the mmap calls to include MAP_POPULATE to get them filled at
> > startup, and now I get this crash. The debug output is from the erlang
> > runtime system's os_mmap function. It seems to turn from the first call to
> > mmap for a 2GB chunk, but asserts shortly after that (and the following is
> > all I get):
> >
> > Attempting to mmap 2147483648 bytes to 0
> > mmaped 2147483648 bytes to address 200000400000
> > Assertion failed: !large() (arch/x64/arch-mmu.hh: next_pt_addr: 82)
> >
>
> Unfortunately, I'm not familiar with this complex templated code, only Gleb
> is (CC'ed).
> *Gleb*, in commit 1b31de0e on of the changes you did was
>
> -inline u64 pt_element_common<N>::next_pt_pfn() const { return pfn(false); }
> +inline u64 pt_element_common<N>::next_pt_pfn() const {
> + assert(!large());
> + return pfn();
> +}
>
> Can you try to recall why you added this assert here (and in a couple of
> other places too). If this assert is really justified, do you have any
> guess what sort of bug may cause it to trigger?
>
My memory is rusty, but looking at the code it seams that the purpose of
next_pt_pfn() is to return a pfn of a next page table level, but for the
pointer to be valid it should not have 'large' bit set, because 'large'
bit indicates that this pte points to a large page instead of next page
table level, so yes, assert is pretty much justified. I have no idea
what can cause it.
--
Gleb.
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
