Re: [BUG] DAX access of Memory Expander on RCH topology fires BUG on page_table_check

[Gregory Price <gregory.price@memverge.com>]

On Mon, Apr 17, 2023 at 11:35:15PM -0700, Dan Williams wrote:
> Gregory Price wrote:
> > Now map and access the memory via /dev/dax0.0  (test program attached)
> > 
> > [ 1028.430734] kernel BUG at mm/page_table_check.c:53!
> 
> I have never tested DAX with CONFIG_PAGE_TABLE_CHECK=y, so would need to
> dig in further here. A quick test passes the unit tests, but the unit
> tests don't have this, "map dax after system-ram" scenario. Just for
> completenees, does it behave without that debug option enabled?
> 

Confirmed passes without issues when this debug option is disabled.
Also confirmed on production hardware with a release build where this
check is disabled.

So something is up with page table check code and going numa to dax.

> 
> i.e. just touching the memory fails, no need to mlock it? This smells
> more like the CONFIG_PAGE_TABLE_CHECK machinery is getting confused, but
> I would have expected its metadata to be reset by the dax device
> reconfiguration.

Yes, just touching is faults, without mlocking it.

I dug in and the page_ext for the page is NULL, which is what causes the
BUG().  I don't know the subsystem well enough to know why converting to
dax would cause the page_ext to be NULL.

The reason why this got convoluted with the other hardware/firmware/bios
issues is that I was thinking the alignment issue with memory blocks may
have been part of the issue, but clearly that's not the case.

~Gregory